Date: 6 NOV 1976 2148-EST
Sender: KLH at MIT-MC
From: KLH at MIT-MC (Ken Harrenstien )
Subject: Mail lost for MIT-MULTICS
To: HEADER-PEOPLE at MIT-MC
Message-ID: <[MIT-MC].13101>

It appears that JFH's message was NOT sent to anyone at Multics,
because their FTP server refuses to handle messages of that length,
and returns an error code of 455.  It was 66,252 chars long
and contained most of RFC724 with comments inserted.
Those of you who saw nothing of this can retrieve the message
from MIT-DMS, filename JFH;RFC724 COMMEN.
  Incidentally, sending that monster occupied 1 hour of real time
for the mailer, and I suggest it not be done again.  COMSAT
does have a limit on the size of mail it will handle; this is
currently set arbitrarily at 81,920 chars (17. ITS blocks,
34. TENEX pages) on the grounds that anything larger is probably
someone trying to gum up the works or send a file the hard way.
I wonder if there should be some recognized limits to the size of
mail?  Exactly how large is the Multics limit?  Other sites?
   (ITS's FTP server will accept any size up to the limits of its
256K virtual core, and then die horribly.  The mailer itself checks
for too-large requests from FTP (or anywhere else), and obnoxiously
large ones are merely pushed aside for someone to look at later.)
-Ken



Date: 6 NOV 1976 2229-EST
Sender: RMF at MIT-MC
From: RMF at MIT-MC (Robert M Frankston )
Subject: Large stuff to Multics
To: HEADER-PEOPLE at MIT-MC
Message-ID: <[MIT-MC].13106>

There is a current limit of (I think) 8000 characters but this is
supposed to be increased in the near future to an indefinite size
due to network users' propensity for sending tomes via this medium.
I don't know what the exact policy is going to be, perhaps Ken (Pogran)
will provide more info on Monday.

Date: 7 NOV 1976 1053-EST
Sender: KLH at MIT-MC
From: KLH at MIT-MC (Ken Harrenstien )
Subject: 724: re JFH and MOON proposals
To: HEADER-PEOPLE at MIT-MC
Message-ID: <[MIT-MC].13175>

   I totally agree with Jack Haverty and Dave Moon that what
we really need is:

[1]  A basic bare-bones protocol; JFH's "SIMPLE" and Moon's
 "absolutely no new features".
[2]  A mechanism for protocol selection between hosts; JFH's
 "RCVMSG", Moon's "framework for this decision making".

   I can't believe that we cannot decide on and constrain sites to
the basic protocol within a very short time, and once that is done
any number of new protocols can be designed and tested in a
non-obstructive fashion using a parallel path mechanism such as
RCVMSG represents.  I would stop here and merely tell people to re-read
both Moon's message and JFH's closing "General thoughts", but
I'd like to add some detail to both of the points above.

On a "basic" protocol:
   This can be done, I believe, simply by producing a definition of
"addressee" that people can live with for the time being.  My
reasoning is that of the basic fields, DATE and SUBJECT are quite well
defined, and the rest (FROM, SENDER, TO, CC) depend primarily on
the syntax of "addressee" to be machine parseable; no doubt this is
one reason why Dave Crocker's RFC 720 was entirely about this subject.
My suggestion is simply that addresses must: (1) have a site
specification, (2) be clearly delimited, and (3) that this delimited
string be acceptable to the given site's FTP server, with the
exception (for compatibility) that names ending in ":" are understood
to be dummies.  The conditions for string delimitation should probably
be as they are now - any sequence of characters excluding space and
atsign.  (basic, remember?)  Those names which need quoting can be
handled later; I really like RMS's suggestion for bracketed names 
(Subject: "Characters that require quoting") and think it should be
in the 724 protocol.
   Notice that I don't consider REPLY-TO basic, although I don't really
mind it; something more limited can be arranged with only FROM and
SENDER.  Similarly for Message-ID; its definition can be postponed
to 724.

On protocol selection:
   One thing I would like to emphasize right off - RCVMSG is
incredibly trivial to implement in a FTP server, if all it does
is negotiate the protocol the user should send over.  To use
basic protocol only requires no change; the RCVMSG will be rejected.
To implement it requires that if a RCVMSG comes in with a type that's
unacceptable, the server say so and suggest the type it really wants.
If a RCVMSG arrives with an acceptable type, a positive reply confirms
the agreement.
e.g.
user: RCVMSG RFC1984     <user requests super duper RFC 1984 protocol>
srvr: 540 RFC1776        <server rejects, suggests RFC 1776>
user: RCVMSG RFC724      <user doesn't like that, tries another type>
srvr: 200 Okay...        <server finds it acceptable, if undesirable>
  While this can be continued for as long as necessary and aborted
anytime, without the final "200" the type remains at whatever it was
last set to (originally "basic".)  Naturally all should accept BASIC.
To implement it on the ITS servers would require 1 table entry,
1 variable, and 10 lines of assembler code; this includes setting
a protocol-identifying switch in the mail text header.  Easy huh?
  Note that this doesn't allow the server to say different things
for different recipients; that is because the problem then appears to
require an XRCP mechanism for specifying recipients independently of
the actual start of mail transfer, and has some other hairs in
the works as well.  I don't see any really good reason why
individual distinction need be made, granted that if a site accepts a
sophisticated protocol it should be able to convert the info
to whatever is desired.

The changes necessary for these two things are, I feel, very small and
will produce far more flexibility than any single protocol could
define, however long and valiantly RFC 724 is discussed and revised.
In this I trust I am merely agreeing with Moon and JFH.

Any other people standing up, pro or con?

-Ken

DATE: 8 NOV 1976 0828-EDT
FROM: JFH at MIT-DMS
SENDER: JFH at MIT-DMS
SUBJECT: Huge Messages
ACTION-TO: HEADER-PEOPLE at MIT-MC
MESSAGE-ID: <[MIT-DMS].43418>

Sorry about that.  I have seen messages at least as large flying
around the net before, so I didn't think anyone would have a problem.

You may have noticed that the message had a line close to the front
labeled 'Enclosure ...'.  This is a feature of our internal mail
system which has proven useful in avoiding problems of huge messages.
The actual message is the few lines before the 'Enclosure'.  The
text, as passed around in the 'message' contains a pointer to
a file -- i.e. the enclosure.  The various mail printing programs
know about the syntax of a file-pointer, and generally append it
to the text when encountered during a printing operation.  Individual
receivers can also have their own 'printing format', which instead
of printing the whole disgusting mess in your mail file just prints
a note containing the file name -- this is what the 'enclosure ...' line
is for.  For net mail there is no such convention, so unfortunately
the whole thing goes over, headed by the single line note of where
it came from.

					Jack

   

DATE: 8 NOV 1976 1015-EDT
FROM: JFH at MIT-DMS
SENDER: JFH at MIT-DMS
SUBJECT: Ken Harrenstien's RCVMSG operation
ACTION-TO: HEADER-PEOPLE at MIT-MC
MESSAGE-ID: <[MIT-DMS].43424>

Ken et al,

Simple enough.  I suggest a simple change, to reduce the delays
caused by bouncing msgs back and forth -- allow any number of
protocol names after a RCVMSG or reply, with the general
convention that they come in order of preference, and the other
site should pick one.

How about the following:

RCVMSG syn1 syn2 syn3 ... synn
 -- user asks the server to accept a message in any of the listed syntax choices,
    which are listed in the user's order of preference

Possible replies are:

540 syn1 syn2 syn3 ... synn
 -- server rejects all of listed syntax choices, and offers alternatives, in
    server's order of preference

or

200 syna syn1 syn2 ... synn
 -- server accepts 'syna' 'syntax accepted', and lists alternatives for the
    user's perusal.  If the user sees something preferable, it may change
    the syntax.  The semantics of this reply are that the server is happy
    with the selection, but has other more preferable alternatives, which were
    not listed in the RCVMSG.
    This is mostly useful when experimental syntax choices are available, which
    the user may handle, but not feel inclined to include in all RCVMSG commands
    because so few servers accept it.

or

XXX Unknown Command (I can't remember the code)

If the user is happy with 'syna', it issues a MLFL or MAIL command to begin
transfer in that syntax.  Alternatively, it is permitted to issue another
RCVMSG with one of the alternatives as a single argument, which should be
acknowledged by a 200 (else bug in server)

If the 540 reply was received, the user must issue a RCVMSG with one
of the syntax choices listed in the 540 reply, or SIMPLE, which, by def'n,
is accepted by everyone.

If the 'unknown command' is received, the user issues a MAIL or MLFL and
sends the message by RFC680 et al syntax -- i.e. this makes existing servers
work immediately in this protocol.

Example:

user: RCVMSG RFC1984 RFC724 
server: 200 RFC724
user: MLFL ...

More complex example:

user: RCVMSG RFC1984 RFC724   <like one of these?>
server: 200 RFC724 STRUC      <yes, but have you ever heard of STRUC?>

At this point, if user issues a MAIL or MLFL, it is assumed to be
in RFC724 syntax...

If, on the other hand, user spots a better choice in the 200 reply, it can
request a change (which should be accepted -- else there is a bug in server)
Note that the second RCVMSG has only one valid argument, and its reply must
be a 200, whose argument better match that of the RCVMSG, and other
arguments, if any, are ignored.

user: RCVMSG STRUC            <yes!!...>
server: 200 STRUC ...         <we both speak STRUC>

----------

Any other FTP people care to comment on implementation?  Hard?  Easy?


P.S. Any comments or arguments pro or con on the general idea of protocol
negotiation to select a syntax for transmission of the message?  Would be
nice to get a consensus before further discussion (if any is needed) of details
like RCVMSG.

                                           Jack

   

Date: 08 NOV 1976 1133-PST
To: Header-People at MIT-MC     
From: Hathaway at AMES-67
Subject: Negotiation of protocol for message HEADER syntax

It seems to me there are already at least two high level
protocols which support some notion of negotiation: TELNET
and FTP.  In TELNET it is really defined as a negotiation: 
either the user or server can initiate the negotiations,
and either can refuse.  In FTP it is strictly up to the
user to request a change of state, and the "negotiation" 
is limited to a "yes" or "no" by the server.  For example,
TSS likes record oriented files, so our user always sends a
STRU R command.  If accepted, fine; if rejected, also fine.
Likewise "negotiations" can take place about byte size, 
character set (ASCII versus EBCDIC), and so forth.  But in
all cases it is the server who rules completely.
 
The reason I point up these existing "negotiation" facil-
ities is to ask "Have we learned anything from them?"  I am
not trying to say either "Yes, TELNET negotiation is tre-
mendous and all negotiation facilities should copy it ex-
actly" or "FTP parameter specification is horrid and should
never have been thought up."  I am simply saying that if
anything at all has been learned, one way or the other, we
should be building on that experience.  As far as I have
seen all proposals for negotiation about mail syntax are
brand new inventions, building on neither TELNET nor FTP.
This may indeed be valid -- again, the two existing facil-
ities may be atrocious -- but I feel the reasons for re-
jecting current approaches should at least be stated.
 
Personally I see nothing wrong with using the existing FTP
mechanism: have a default syntax for MAIL/MLFL and have a
command to change it.  This follows the simple RCVMSG, I
think, as well as existing FTP concepts.  The extended
RCVMSG proposed by Haverty, on the other hand, seems more
like TELNET: 
 
         (user)    DO RFC724
         (server)  WONT RFC724; DO STRU
         (user)    WILL STRU
 
although I realize in the example given by Haverty the
user could have gone ahead and accepted the RFC724.  This
could be handled above by the server rejecting the DO STRU
and then countering with another DO RFC724, in which case
the server could say, "Well, RFC724 is better than the
default, so okay -- WILL RFC724."  At any rate, the point
is that either the user or the server can initiate change.
 
At the risk of becoming even more of a pain than I usually
am, I will repeat my plea -- before we reinvent another
wheel let's at least look at what we are riding around on
today.
 
                                Wayne 
 
PS: Isn't the name "RCVMSG" a bit obscure for negotiating
mail header syntax?   W.
------

Date: 8 NOV 1976 0909-PST
Sender: FARBER at USC-ISI
Subject: The state of the discussion on the proposed RFC
From: FARBER at USC-ISI
To: Header-people at MIT-MC    
Message-ID: <[USC-ISI] 8-NOV-76 09:09:55.FARBER>

Gents,

I don't mean for this to sound like a squelch but:

1.  Can  we  handle one thing at a time.  There is on the floor a
proposed  RFC  that  is  submitted  for  comment.   Lets   finish
substantive comments on it by the requested date of Nov 23 rd.

2.  With  respect  to  the  JFH  and  Moon comments can we have a
concrete proposal for such a mechanism after the comments on  the
proposed  RFC  are completed.  I personally am not convinced that
the suggestion will not generate more effort and confusion in the
message area than it solves and that it will not generate a large
number of incompatible protocols that almost no one can use.   It
is  somewhat  analogous  to  the  effect  that  one would have if
letters were treated that way.

  Given the two above items , CAHCOM can then evaluate the impact
and effect of the choices (including the one of doing nothing).

-------   

Date:  8 Nov 1976 1315-EST
Sender: PK01 at CMU-10A
Subject: Re: 724: re JFH and MOON proposals
From: PHILIP KARLTON at CMU-10A
To: HEADER-PEOPLE at MIT-MC
Message-ID: [CMU-10A] 104662 PHILIP KARLTON
In-Reply-To: <[MIT-MC].13175>


This is a reiteration of one small plea.  Why not allow the spaces in
addressee names.  It is just not that difficult to look for the "@" or
" at " and assume the stuff before it is the name.  If the FTP server
at the local site will not accept the name with spaces, then the mail
sender should not put out names that way.

Phil

-------

DATE: 8 NOV 1976 1730-EDT
FROM: JFH at MIT-DMS
SENDER: JFH at MIT-DMS
SUBJECT: RFC 724 comments and RCVMSG proposal
ACTION-TO: FARBER at USC-ISI
CC: HEADER-PEOPLE at MIT-MC, VEZZA at MIT-DMS
MESSAGE-ID: <[MIT-DMS].43444>

Maybe I can clear up some things:

1/ I was concerned at the lack of any spec as to how RFC 724
headers would be adopted.  There is considerable difference
between the current 'ad hoc' standard and the one proposed
by RFC 724.  Changing the format in the same fashion as
past syntax defn's were done could conceivably have significant
impact on existing levels of service.

2/ Without knowing how it would be adopted, it is hard to express
an opinion as to whether it is worth while.  Part of the RFC implied
that there would in fact be some non-zero disturbance of the
mail service as change-overs occurred.  There is clearly some
relation between gains with adoption of RFC 724 and disruptions
during its adoption.

3/ The RCVMSG proposal was intended to present a means of adopting
RFC 724 (or any new mail syntax for that matter) in a minimal, possibly
totally, non-disruptive fashion.  It would also permit splitting
up the various aspects of the RFC 724 proposal -- for example,
to have one header -- SIMPLE -- which would be minimal, easy-to-read,
and generally satisfy the sites with no complicated mail reader programs.
The second protocol, call it EXACT for convenience, would not necessarily
be pretty, but would contain all the data needed by sophisticated mail
reader programs to do a reasonable job.  
The RCVMSG framework would also pave the way to adoption
of any number of future protocols, and provide the environment for
experimentation with structured mail, voice, graphics, and other protocols.

4/ My overall opinion of RFC 724 is that it is considerably more
complicated than 680 and friends, and addresses new issues which we
have not by any means figured out how to do 'right'.  As such, it must
be considered experimental and subject to change.  It attempts to
satisfy what, to me at least, seem to be conflicting goals -- to provide
readable headers, and to provide all the data needed by complex
mail systems.  I believe that it would be easier, as well as better, to split
the problem into components along those lines, and avoid compromises
which seem unnecessary.

5/ Perhaps with Ken Harrenstien and Dave Moon, we can come up with
a more specific proposal along these lines to serve as an
alternative -- the RCVMSG protocol, a SIMPLE header syntax, and an
EXACT header syntax should be a good start.  I will talk to
Ken and Dave about it.

                                           Jack

  

Date:  8 NOV 1976 2201-PST
From: POSTEL at USC-ISIC
Subject: path names
To:   Header-People at MIT-MC

if we want to take on the path names problem too, do take a look at rfc 645.
--jon.
-------

From:  Pogran at MIT-Multics
Date:  11/09/76 1017-est
Subject:  Re:  Large stuff to Multics
To:  Header-People at MIT-MC
Message-ID:  [MIT-Multics]1.1.BBBJGCJMknhWwp

Yes, there IS a limit on the size of mail Multics will accept.
This happens to be due to a deficient implementation, rather
than any basic design flaw in the Multics message mechanism.  The
current limit is (2**19-1)/9 characters; as Bob Frankston mentioned,
this should change sometime soon.

Ken Pogran

Date: 9 Nov 1976 1859-EST
Sender: VITTAL at BBN-TENEXF
Subject: Some comments (RFC724, etc.) ...
From: VITTAL at BBN-TENEXF
To: Header-People at MIT-MC   
Message-ID: <[BBN-TENEXF] 9-Nov-76 18:59:57.VITTAL>  

Folks:  

I'd like to make some comments on behalf of the authors of RFC724
addressing some of the recent Header-People discussions.  

RFC724 is intended as a SYNTAX and NOT a PROTOCOL!  In particular, it
is intended as an interim measure until such a time as a structured
Mail Transmission Protocol can be adequately developed.  We feel that
the Mail Transmission Protocol should be a NEW protocol and should not
get dumped in on top of the existing FTP.  It is not very easy to
change FTP protocols and/or programs; there are some institutions
where there is a significant physical and cultural separation between
mail program generators/maintainers and FTP maintainers.  Because of
this, we explicitly did NOT want to introduce anything which would
force a change to the FTP.  It is important to note that the most
promising candidate for inclusion into an FTP change, at this point,
is Harrenstein's XCRP.  But, even that should not be specified in
RFC724, meritorious as it might be.  

Also, in order to implement the syntax defined in 724, you don't want
to have to interface your mail generating program to a mailer program
and have the mailer program decide what format the headers are to be
in; you want the mail generator to decide, along with allowing the
user of the mail generator some ability to control the result -- both
on the creating and the receiving end.  Then, you want to be able to
tell the mailer to mail the message.  

Now for some comments on the syntax itself.  I agree with most of the
concerns about the fiasco associated with dates.  We specifically left
out any syntax regarding forwarding information.  Just trying to
define the syntax and the semantics so that it is all things to all
people is a gargantuan task; the appropriate place for it is in a
structured mail protocol so that the information can be deciphered in
a reasonable way.  In retrospect, I guess that the audit trail
information probably should not have been included, either.  I agree
that it is a "new" feature, and as such needs more discussion; it
probably doesn't belong in this syntax; I would be in favor of
removing it.  

Assuming that the syntax and semantics for audit trails (the "Edited-
by" and "Inclusions-by" stuff) are eliminated, then let me enumerate
what we view to be the significant differences between RFC680 and
RFC724:  

  1.  A lot of the extraneous syntax in 680 has been removed.  This
      includes all information relating to "Precedence" and so on.  

  2.  We have expanded on the semantics of many of the fields.  

  3.  We have clarified the notion of an author (the differences
      between Sender and From, and the addition of a Reply-to).  

  4.  We have added a clearer notion of what an address is 

  5.  We have added a mechanism for continuation of fields without
      having to respecify the name of the field.  We realize that
      the specification of how to do this in the syntax was not as
      good as we wanted, and it will be better on the next
      iteration.  The important thing is that we know what we want,
      we have a reasonably good line-continuation syntax; RFC680 did
      not.  


All that automatic message systems need concern themselves with are
the new address format and how to automatically define recipient lists
for a reply to a message.  In particular, there is NO need to modify
the FTP.  But, more on this some other time.  

With regard to Jack's (Haverty's) proposal for a bidding sequence
between a local message system and a remote FTP server, let me make a
simple comment.  If the message system itself does not interface
directly to the remote FTP server, you are in trouble.  What happens
if you can only generate one form of message and a receiving host
can't accept it?  Does that mean that you can't send mail?  

Since Ken (Pogran) knows much more about FTP and real honest-to-
goodness protocols than I, he has promised me that he will make some
comments soon.  

The intent of this message is not to try to squelch discussion on
either 724, structured protocols, or bidding scenarios.  All are
viable discussion topics, but I strongly feel that they should be
separated, since they are separate issues.  

Sorry to have been so long winded.  

John Vittal (for the CAHCOM subcommittee) 
-------   

Date:  9 Nov 1976 (Tuesday) 2004-Est
From: STECKEL at HARV-10
Subject: KLH, MOON, & 724
To:   HEADER-PEOPLE at MIT-MC

ABOUT 70,000 CHARACTERS AGO I THOUGHT THIS WAS AN EASY PROBLEM.

1) "SIMPLE" FIXES - EMPHATICALLY THE ONLY THING THAT CAN
 BE DONE AT PRESENT.  THE TOPS-10'S COOPERATE, BUT I DON'T KNOW OF
 ANY OF US WITH LOADS OF TIME TO CHANGE MAIL/FTPSRV, ESPECIALLY AS THE
 SOURCES ARE SPREAD AROUND.

2) NEGOTIATED SYNTAX.  A GOOD-LOOKING IDEA, BUT I THINK IT WILL
 PROMOTE CLUBBISHNESS (E.G. ITS TALKS ONLY TO ITS, TENEX TO TENEX).
 IMPLEMENTATION TIME?  LONG....

3) RESTRICTIONS ON THE BODY OF MAIL.  THAT IS NOT OUR PROVINCE.  EARLIER
 COMMENTS ABOUT CASE APPLY: MAKE THE HEADER INTO SOMETHING ACCEPTABLE TO
 ALL SITES, BUT MAIL CAN ENCLOSE ANYTHING AT ALL.  WITH THE CURRENT
 SECURITY CRAZE, IT IS OFTEN DIFFICULT TO GIVE SOMEBODY A FILE OVER THE
 NET; MAIL IS AN ACCEPTABLE ALTERNATIVE AS NO ONE HAS TO RELEASE PASS-
 WORDS.  I ALSO AGREE THAT GENERAL MAIL SHOULD NOT CONTAIN "BOMBS"
 IN THE FORM OF TABS TO A SITE THAT DOESN'T WANT THEM.  THE ETIQUETTE
 IS CLEAR: TO STRANGERS, WATCH YOUR LANGUAGE; TO FRIENDS, ANY
 THING YOU THINK THEY WILL LIKE.

4) FARBER'S COMMENT - I DON'T THINK 724 WILL SOLVE ANYTHING.
 IT LOOKS LIKE A WAY FOR PROGRAMMERS TO KEEP JOBS SECURE.
 I'VE GOT ENOUGH WORK.


5) [CMU-10A] 104662 PHILIP KARLTON - YES.  HUMAN READABLE, YEA!


Date: 10 NOV 1976 1125-EST
Sender: KLH at MIT-AI
From: KLH at MIT-AI (Ken Harrenstien )
Subject: Revised RCVMSG proposal --> XHDR and "S:"
To: Header-people at MIT-MC
Message-ID: <[MIT-AI].24864>

   Even before Vittal pointed out problems in trying to interface
a local mail generator directly to the remote FTP, both JFH and
I realized that this would be difficult for other sites to
handle; we no doubt think in terms of central mailer demons, which
both COMSYS and COMSAT are.  However, the issue of adapting to
new and experimental protocols is quite important, and I feel that
regardless of how 724 is resolved, we will need to provide such a
protocol negotiation (or syntax switching, if you wish) facility.
I don't believe a structured, parallel protocol will be developed
or even implemented for a long time to come.

REVISED PROPOSAL - XHDR and "S:"

  So, here's a revised proposal which, I hope, can make everyone
happy.  The major idea here is to specify the syntax/protocol in
the header itself!  For this I will postulate 3 classes of header
syntax:

[1] SIMPLE - This is THE basic syntax, which ALL sites are required
     to support (both sending & receiving).  It is intended to
     require the absolute minimum of change to existing systems,
     and uses neither FTP negotiation nor syntax specification.
[2] <RANDOM> - This class contains any non-SIMPLE syntax which does not
    need explicit FTP negotiation.  It does require that the particular
    syntax used be specified in the header, (see below for "S:")
    and that the sender be sure that the receiver supports it.
[3] <ADVANCED> - FTP negotiation required for these, implying that
    some special actions are necessary and that the server itself must
    mark or handle the message accordingly; "S:" is not used.


DESCRIPTION OF "S:"
     One reason for FTP negotiation is to enable the server to know
what type of syntax is coming across, so that it can be marked
appropriately for the mail reader.  This can be eliminated if the
header itself always specifies its syntax!  To do this, the very first
item must be:
            S:<sp><word><newline>
   e.g.
S: RFC724
Date: (Xmas) Twenty-fifth of Dec '76 1 am+54 min BZT
From: etc.

If absent, the syntax is SIMPLE by default.  If non-SIMPLE and not in
the <ADVANCED> class, then "S:" must always be present.  By specifying
it first, the rest of the header can be parsed accordingly.  By 
specifying it as a "normal"-looking header item, it can be parsed with 
the SIMPLE parser, thus ensuring one always begins with the right parser
and can always understand/ignore the item as the case may be.
(Two minor helps: it's a SHORT keyword for easier testing, and
can easily be "filtered" simply by starting a printout right after
the S: line.)

DESCRIPTION OF XHDR
   As for FTP "negotiation", allow me to define a combination of
my and JFH's earlier ideas, which I will call XHDR to avoid confusion
and use 4 letters (there once was a RFC discussing the length, I think).
The initial "header-syntax state" of a FTP server is UNDEF rather than
SIMPLE.  That is, any mail received while in the UNDEF state is either
SIMPLE or possesses a "S:" syntax specification in the header; the FTP
server need do nothing at all, and thus all current servers support
UNDEF!
  To query the server about what it likes, or to agree on what
syntax should be used, the user side gives:
XHDR <syntax name>         ; Suggest 6 chars max for names.
                           ; a null name is the same as UNDEF!
   To which the server must reply either:
200 <syn1> <syn2> <syn3>...    ; accepted
   Or:
540 <syn1> <syn2> <syn3>...    ; rejected
   Or:
4xx/5xx (except 540 or whatever is used).  Server doesn't understand
      XHDR, so state remains at UNDEF.

   Regardless of whether the reply is 200 or 540, the same string
is ALWAYS used for <syn1> <syn2> etc. to describe all the syntax
types which the site supports, in order of preference.  UNDEF and SIMPLE
are always implicitly supported, so need not be shown.  Any number
of XHDR's may be given; the last accepted (or UNDEF if none)
tells the server what sort of stuff the user is going to send, which is
needed for <ADVANCED> stuff and provides an optional check for <RANDOM>
types.  I think this scheme preserves essential FTP simplicity while
allowing some degree of cleverness as JFH suggested.


USE - HOW TO SEND RIGHT THING
   Okay, how does the mail generating program know what syntax
to use?  How do you prevent sending a S: RFC724 header to a
SIMPLE-only server which, in the UNDEFINED state, accepts blindly?
This is no problem for senders which attempt XHDR querying, but what
about those which can't or don't want to grill the FTP server?
The solution here is not elegant, but is practical and quickly
done: keep a host table/file.  Every mail program already does this
for hostname lookup.  It follows that:
 a)  Those sites which cannot generate other than SIMPLE headers
have nothing to do, since every site is guaranteed to understand
SIMPLE.
 b)  If a mailer wishes to implement a new RANDOM syntax, it
is simply part of the necessary implementation that it be
responsible for generating this syntax intelligently; that is, it
must either use XHDR, or maintain a table telling it which sites
are known to understand the new syntax.  Actually adding the "S:"
is trivial.
 c)  When a site becomes capable of receiving a new syntax, they
must announce the fact by means of a mailing list such as
HEADER-PEOPLE, so that those maintainers using tables can update
them.  Late updates are only an annoyance rather than a screw,
since presumably once having advanced past SIMPLE a site will
not suddenly regress backwards.  Thus no site should receive
anything it can't understand, and if by some bug it does, the fact
will be obvious due to "S:".

***********************************************************
                       SUMMARY
***********************************************************

   Thus, this scheme requires NO effort on the part of anyone
who is happy with the SIMPLE syntax, other than that of conforming
to it (and we would try to keep those conformance changes minimal).
People who are eager, desperate, or paid enough to desire the
use of a new syntax have only to implement:
          For Sending:
* Use a table or XHDR querying to prevent sending
   new syntax to ignorant site.  (straightforward)
* Use "S:" when new syntax generated. (very trivial)
          For Receiving:
* Mail reader must check for "S:".  (easy.  Attempt to read new syntax
   as opposed to SIMPLE implies one has such a reader-program)
* Network must be notified that you now accept it (Just send message)
* FTP server should have XHDR (trivial)

Note that most of this is "one-time-only", when a site is ready to
make its leap into the brave new-syntax worlds; after that, the overhead
is just table updating.  Also, given "S:" and a table for the mail
generators, XHDR is not really necessary... but using it allows giving
instant and accurate status, it is better suited to distributed
interactions, and is necessary for <ADVANCED> types to work; the future
structured protocol could easily be an <ADVANCED> type initially or
experimentally.
**************************************************************

Lastly, on FTP Support of Mail:
  This brings me to my last point about this proposal: Vittal
says that "there are some institutions where there is a
significant physical and cultural separation" between Mail and FTP
people, implying that "our/their FTP maintainer won't do it".  Sorry,
but I don't believe that.  I realize that if you do not directly
control a program yourself you cannot make statements about what
will or won't be done to it; however, as a FTP maintainer, I repeat
that if you DO want to implement XHDR it will take less than the time
I've spent typing this message!  I've read through the TENEX FTP
server listing, and could add the code just as easily as for the
ITS server, so you certainly have no problem there, and neither should
anyone else.

-Ken

P.S.  Re "proliferation" and "clubbishness".  Nothing stops anyone
from defining their own (mail or otherwise) protocols for their own
sockets, and many have done so, and the network is all the better for
it.  Furthermore, net mail is clearly a global protocol and I strongly
doubt that it will splinter up significantly.


Date: 12 NOV 1976 0914-EST
Sender: GMP at MIT-MC
From: GMP at MIT-MC (Gary M. Palter )
Subject: Mail which was mis-sent by ITS mailer...
To: HEADER-PEOPLE at MIT-MC
Message-ID: <[MIT-MC].14270>

The ITS mailer has some bugs in it.  The following mail was never sent
to HEADER-PEOPLE and was found as a file on MC.
----------

From:     Frankston.CompSys at MIT-Multics (Robert M. Frankston)
Date:     10/30/76 1054-edt
Subject:  rfc724
Message-ID:  [MIT-Multics]1.2.BBBJGBWFmFXXGz
To:       header-discussion at MIT-MC

For Multics users I have a copy of the RFC on Multics
without tabs as >udd>CompSys>Frankston>md>rfc724

It should stay there for a few days for so.
^_
RMF@MIT-MC 10/25/76 15:38:07 Re: message id's and corrections
To: HEADER-DISCUSSION at MIT-MC

I just ran into a typical problem that is closely related to message
id's.  I made an error in the address list and would like to resend the
letter with the corrected address list but some copies have already gone
out to people whose address was specified correctly.  At a first cut I
would like to send the letter out with the same message-id so that
those who receive a second copy will be able to discard it.  The problem
is that message forwarding centers such as ITS will discard it because
they have already seen a message with the same ID.  What is needed is
a revision number that distinguishes instances of a message from each
other.  Yes, this is admitting that the message id is not a message id,
and seems to back off from a hoped for simplicity.  On the other hand
it is keeping standard businesss practice and is very simple according
to the following rules:
	a. There is a message-ID and a revision number.
	b. To messages are duplicated if their message-ID's are
	   identical and their revision numbers are identical.
	c. If the message-IDs match but the revision numbers are
	   different the one with the higher revision number is
	   retained.

These means that one only need retain the message ID and the most
recent revision number.
^_
DATE: 30 SEP 1976 1311-EDT
FROM: JFH at MIT-DMS
SENDER: JFH at MIT-DMS
SUBJECT: RE your message to MSGGROUP about from and sender...
ACTION-TO: HOUGH at OFFICE-1, HEADER-GROUP at MIT-MC
CC: STEFFERUD at USC-ISI, FARBER at USC-ISI
MESSAGE-ID: <[MIT-DMS].40984>

1/ I believe CLERK was proposed at one time in the distant past,
and rejected in favor of SENDER because it was thought that
CLERK would be somewhat demeaning to the person involved.

2/ There are lots of other possible people (not necessarily
all distinct) associated with a message.  For example,  
RELEASED-BY -- the person who said it is ok to send
AUTHORIZED-BY -- the person who approves of the 'content'
SENT-BY -- what SENDER is now
REPLY-TO -- who should get the answers
REQUESTED-BY -- who asked that the message be composed, e.g.
	a manager may ask a staff member to compose some
	information into a message
AUTHORED-BY -- the person who actually wrote the stuff
COLLABORATORS -- people who assisted the AUTHORED-BY
CO-AUTHORS -- others who assume equal responsibility
	with the AUTHORED-BY
etc. etc. etc.  In all of these cases, it is reasonable
(except for SENT-BY) to allow any number of names, etc.

3/ The concept of a 'person' is inadequate.  Often a 'position'
is also necessary.  For example, someone can act as himself
in a personal sense, as holder of some office within an organization,
etc.  This can significantly change the meaning of anything
such a pseudo-schizophrenic may say.  In the military, the problem
is handled by requiring that all messages be from 'the commander'
in some fashion -- e.g. this message would be from 'MIT-DMS', not
'JFH@MIT-DMS'

4/ The common occurrence in current mail where a person sends a message
using another account complicates things further.  For example,
the message which Panko sent was signed by him, but the header
alleged it to be from HOUGH@OFFICE-1.

------

A comment:  The problem is much more complex than most people think.
It is not clear that a 'standard' can be created which simultaneously
satisfies the needs of all users on the various sites.  Even if it can,
it may be prohibitively expensive, if the vast majority of messages
fit some simple form, e.g. a short note from a single real live person
to another single person, with no replies, references, etc. involved.
Systems which are forced to consider all the possibilities all the time
are necessarily more complex, difficult to program, maintain, debug, etc.

A proposal:  Has anyone ever considered that there is no inherent need
for a single MAIL SYSTEM, or even a STANDARD HEADER.  Possibly it would
be more reasonable to consider having several separate mail paths, each
suited to a different class of message/user.  The real world analog
has the US Postal Service, UPS, Air freight, Western Union, Carrier
Pigeon, Radio, and so on.  It might be worth thinking about.  A lot of
problems associated with changeovers in THE STANDARD could also be avoided
if new systems were phased in and the old allowed to die through
disuse over time.  I'm not sure what ramifications this would have at the
various sites -- presumably each service would require a separate
'port' (socket to ICP to, or command to direct a message to various
handlers for different systems).  Any comments?

					Jack Haverty
					(JFH@MIT-DMS)

  
^_

Date: 12 NOV 1976 1654-EST
Sender: KLH at MIT-AI
From: KLH at MIT-AI (Ken Harrenstien )
Subject: Bugs in ITS mailer?
To: Header-people at MIT-MC, GMP at MIT-MC
Message-ID: <[MIT-AI].26010>

Before you assume the mailer is buggy, take a closer look at
the messages in question.  None of them are addressed to
"Header-people", are they? There is Header-discussion and
Header-group, but nothing that requires the mailer to ship it
to Header-people... 
   If a local user sends to an unknown name, COMSAT can certainly
report back to him that the name is unknown.  However, for mail
coming in from the network, the FTP server has no access to the
complete mailbox mapping/translation/options service that COMSAT
provides, so it can't rule on the legality of a name; and COMSAT
simply gives up on parsing a network header so as to report back to
the sender.  The same situation exists on MIT-DM for COMSYS, except that
JFH has tried very hard to make this parsing/reporting possible, which
is one reason why he is touchy about machine readability.  Me, I
sympathize completely - I looked at his efforts and gave up the idea of
snaring myself likewise, until a decent protocol becomes fact.

So far, no noises about 724, "S:", etc...
-Ken


Date: 12 NOV 1976 1846-EST
Sender: GMP at MIT-MC
From: GMP at MIT-MC (Gary M. Palter )
Subject: Bugs in ITS mailer?
To: HEADER-PEOPLE at MIT-MC, KLH at MIT-AI
Message-ID: <[MIT-MC].14425>

Sory Ken.  However, as CBF has reported there were a number of messages
to BUG-TMACS that didn't work (including on MC where I know there is a
BUG-TMACS entry).

Date:  8 Nov 1976 2021-EST
Sender: RG02 at CMU-10A
Subject: NIC idents
From: RICK GUMPERTZ at CMU-10A
To: Header-people@MIT-MC
Message-ID: [CMU-10A] 105876 RICK GUMPERTZ

Perhaps there should be a syntax for easily specifying unique names
which may be used for comparing people names.  For example, if we
were to choose << and >> as delimiters (not a suggestion), one might say:
	Rick Gumpertz <<RHG>> [machine-addr]

For now, the unique name could be NIC idents (they are still being
issued!).  Some future mechanism might replace this with some other
unique name in the future.  One might even envision someday allowing
use of such idents as addresses for forwarding by some central
dispatcher (or am I going full circle here?).

		Peace,
		Rick

-------

Date: 16 NOV 1976 1541-PST
To: Header-People at MIT-MC     
From: Hathaway at AMES-67
Subject: 263 rather rambling lines about "XHDR" and "S:"

Relative to KLH's "XHDR AND S:" proposal, I have one large
question, a larger objection, several small nits, and per-
haps a counter proposal (depending on how good it looks by
the time I get to it).
 
First the question.  Obviously when we hypothesize new 
versions of mail handlers etc we must have some model of
such a system in mind.  But to date I have seen no dis-
cussion of this model at all, and perhaps this is causing
much of the problem.  I remember way back at the start of
this when Stef pointed out the dichotomy between smart mail
receivers and dumb ones, and how some of us assumed one
thing and some another.  But that's about the last that
this was discussed -- until now ...
 
It seems to me that there are four "things" which get in-
volved in a mailing operation (not including human beings): 
 
  1) The "mail creator" -- some means for the human to
     put his thoughts into machine readable (and pre-
     sumably machine resident) form.  I suppose one
     reasonable implementation of this would be "the"
     text editor (i.e., the same editor that is used
     to create source and data files, documentation,
     etc.).
 
  2) The "mail sender" (a/k/a "user FTP") -- takes the
     mail created above and causes it to be transmitted
     to the desired recipient (with possible insertion
     of headers, queueing for later delivery, handling
     of copies, etc.). 
 
  3) The "mail receiver" (a/k/a "server FTP") -- accepts
     mail from the net (in response to MAIL and MLFL com-
     mands) and "does the right thing with it" (stores it
     into a file, routes it to a printer, etc.).
 
  4) The "mail reader" -- takes the mail as stored by
     the FTP server and "presents" it to the user (as-
     suming the FTP server in fact stored the mail in
     a file).  One simple implementation of this would
     be a program to type the file verbatim.  More com-
     plex programs would provide selective reading, 
     automatic answering, etc. (and could of course be
     closely related to the "mail creator" above).
 
Discussions to date have been almost exlusively about the
interplay between the mail sender and mail receiver, but I
feel other interactions are also of interest.  For example,
does the mail creator or mail sender add the header?  The
"negotiated header syntax" concept implies it is the sender,
as that is the user's negotiating element.  I can also see
arguments for having the creator generate the header, mostly
to do with interaction with the user.  And having these two
jobs done by one process is not really the answer either, as
for example in the case of delayed sending (after the user
has disconnected). 
 
At any rate, the most questionable interaction seems to be
between the FTP server (mail receiver) and the mail reader.
Specifically the question of how much does the FTP server
look at the mail it is receiving:  does it simply stash it
away in a file, does it add headers and trailers and such
(for example, to time stamp the actual receipt of the mail,
as contrasted with the "time of sending" in the header), or
in fact does the FTP server parse the header?  For any of 
the new proposals to work it seems that this latter choice
must be made, and to me this is wrong -- it seems that the
FTP server should be no more interested in the contents of a
mail file than in any other text file, with all parsing etc
being performed by the mail reader.  I realize there are
problems with this in current implementations (for example,
the FTP server might like to use the FROM: line in naming
the file), but more is said on this later.  Mainly I would
just like to question what (if any!) models have been used
in coming up with suggestions to date?
 
Okay, how does the "XHDR" and "S:" proposal relate to all
of this?  As mentioned above, full use of "XHDR" seems to
require that the mail sender be the header creator, which
requires that the user must include enough information in
whatever the mail creator creates to allow construction of
any type of header that the sender might support.  This
seems undesirable at best.  The "S:" option does not re-
quire as much here, as the sender chooses the syntax (as-
suming it knows the receiver supports <RANDOM> -- more on
that later!).  It does require the FTP server to look into
the file, however, and I still must object to this.  Maybe
a "reductio ad absurdum" argument will illustrate why I feel
the way I do.  Let's consider an equivalent scheme for the
"STOR" command, in which the argument of "STOR" specifies
the username (and password etc) under which the file will
be stored.  So where does the file name come from?  How 
about including it as the first line of the file ... ?  I
know this is a violation of the "command connection versus
data connection" concept, and is of course totally absurd,
but isn't it pretty close to what is being proposed for
mail?  Before giving my alternative proposal, let me first
give my strong objection and nits.
 
 
Here comes -- I must object very VERY
 
    SSS   TTTTT  RRRR    OOO   N   N   GGG   L    Y   Y
   S   S    T    R   R  O   O  NN  N  G   G  L    Y   Y
    S       T    R   R  O   O  N N N  G      L     Y Y
     S      T    RRRR   O   O  N  NN  G  GG  L      Y
      S     T    R R    O   O  N   N  G   G  L      Y
   S   S    T    R  R   O   O  N   N  G   G  L      Y
    SSS     T    R   R   OOO   N   N   GGG   LLLLL  Y
 
to ANY official sanctioning of ad hoc tables of "what other
hosts like"!!!!!  (Emphasis added by the author!)  There is
to date one official version of such a table, the host name
list maintained by the NIC.  Even with all the plusses this
list has -- it is "official," it has paid personnel to main-
tain it, it is easily available via FTP, it really contains
only information which should be relatively permanent -- it
is still out of date for some host just about all the time.
Can you imagine how ridiculous it would be to have literally
dozens of such lists, for each of several different items
(mail header, TELNET, FTP, other services, etc), all being
maintained without any centralized or even well defined 
mechanism for updating/reviewing?  Oy veh, the mind boggles!
Seriously, let's PLEASE resist such things at all costs.  If
there really is something that hosts need to know in advance
about other hosts, then it should be added to the one and
only official host information list, the one maintained by
the NIC (which does in fact contain information other than
host names, specifically nicknames and status).  But I
really feel that everything should be handled by some form
of negotiation, even if nothing more than what Multics does
for MAIL versus MLFL: try MLFL; if rejected use MAIL.  This
seems so much better than things like the table "maintained"
by CMU.  I mean really, if a user says "Initiate Protocol X
with Host Z" are you really going to respond "Sorry, but ac-
cording to my table Host Z does not support Protocol X, so I
am not going to try"?  One would hope not!
 
 
Okay, now for the nits about Ken's proposal ...
 
For one thing, you are making assumptions about FTP servers
and mail readers.  For example, "it can be parsed by the
SIMPLE parser" -- who says an FTP server must have ANY par-
ser?  I can visualize servers which might not even be ABLE
to look into a file as it is received!  (By the way, I am
assuming MLFL in all cases.)  Also about the host table, you
state that "Every mail program already does this for host-
name lookup."  Apart from what I said earlier about why the
hostname file is different, this is not necessarily true.  I
agree that SOMEWHERE in a user NCP there must be such a
table, but the "mail program" may not have any special ac-
cess rights.  For example, consider a system in which the
mail creator simply passes the hostname as typed by the user
on to the user FTP for sending.  The mail creator may not be
able to interrogate the table by himself, only the user FTP.
I'm not expounding this approach, of course, just warning
against assumptions again.
 
You also state that if a site should receive something it
can't understand (presumably meaning <RANDOM> when all it
can hack is SIMPLE), then "the fact will be obvious due to
'S:'."  Obvious to whom?  I thought SIMPLE FTP servers would
be able to just stash things in files for later processing
by mail readers?  I guess it might be obvious to the mail
reader when it tries to parse an unexpected header syntax,
but that seems a bit late.
 
 
And now (finally!) my rather radical proposal ...
 
Whereas: the implementation of "XHDR" will in fact require
at least some modifications to both user and server FTP's,
and
 
Whereas: the use of "XHDR" will require that header gener-
ation be actually done by the "mail sender" (user FTP), im-
plying that the sender has enough information to do this 
job, and
 
Whereas: the whole idea behind letting the "mail receiver"
(server FTP) know what syntax is being used is to allow it
to do "appropriate things" to the mail as it is being stored
for later reading,
 
Be it proposed that: the well-accepted convention in FTP of
separation of header information and data be continued.  To
wit, header information should be sent over the command con-
nection and data should be sent over data connections.  In
the specific case of mail this could be done by defining one
additional FTP command, say XMAIL, to be used as follows: 
 
         XMAIL FROM: Hathaway at AMES-67
         200 Gotcha.
         XMAIL SUBJECT: Another over-long proposal
         200 Gotcha.
         XMAIL TO: Tom, Dick, Harry, <%'*("FILENAME")*'%>
         200 Gotcha.
         XMAIL CC: Rumplestiltskin
         503 Sorry, never heard of the gent.
         XMAIL HERE-COMES
         255 SOCK 123456
              (etc)
 
Sure, I know this is what the "structured mail protocol"
that everybody is waiting for is supposed to do, but is it
really any more difficult to specify than what is going on
right now?  The text of each XMAIL command ("subcommand" or
such if you like) could simply be as defined by RFC724 or
whatever is finally accepted.  And consider the following: 
 
1) It requires very little modification to existing servers.
For one thing, they could just reject the first XMAIL com-
mand, which would require the sender to revert to MAIL or
MLFL and whatever header syntax we are currently struggling
by with (Ken's SIMPLE syntax).  On the other hand, a server
with only a minuscule amount of smarts could just stash the
text following each command into the file, looking only for
"XMAIL TO:" for addresses.  It may be desirable to help it
out by requiring that "XMAIL TO:" be first and defining a
separate reply code for "Sorry, we do not accept multiple
addressees," but this is a minorness.  The new scheme might
even help unusual implementations, such as where header in-
formation is put into individual users' mailboxes but text
is stored in one central file or printed immediately.
 
2) It would allow a smart server to actually parse incoming
COMMANDs (as contrasted with incoming DATA) for such reasons
as marking mail files, creating locally acceptable headers,
handling multiple deliveries with only one network transfer,
and essentially everything else proposed so far.  In fact,
it directly implements both XRCP ("XMAIL TO:") and XHDR
("XMAIL S:")! 
 
3) It eliminates the need for the dreaded "host preference"
tables since it extends the already existing FTP negotiation
facility ("MLFL"/500/"MAIL") to every single header item!
 
4) It allows header processing to be done by either the mail
reader (if the FTP server simply stashes XMAIL parameters in
the mail file) or by the FTP server.  This might help in 
situations where control of one or the other processes is
not readily attainable.
 
5) The concept fits very nicely within current FTP philoso-
phy and can be extended to the <ADVANCED> realm simply by 
the definition of new commands to supplement XMAIL (XITSMAIL
or XTENEXMAIL anyone?). 
 
 
So in closing (whew!) let me say that I have no idea what
will be the fate of this proposal (well, I guess I do have
SOME idea!), but I think there are several things here worth
considering.
 
                                Wayne.
 
 
PS: Ken, about "clubbishness":  I agree that nothing stops
it currently, but I am not sure "the network is all the bet-
ter for it."  Perhaps this rosy outlook is due in part to
your having belonged to most of the clubs?
------

Date: 17 NOV 1976 0550-EST
Sender: KLH at MIT-AI
From: KLH at MIT-AI (Ken Harrenstien )
Subject: Clarification on "S:", XHDR, etc. (???)
To: Header-people at MIT-MC
Message-ID: <[MIT-AI].28624>

In reply to Wayne's message:
   Whenever a idea needs to be put across, there is always a balance
between being overly brief (and having the point missed for
want of sufficient detail) or being overly windy (and likewise
drowning the essentials).  Apparently I miscalculated again, since
I actually agree with Wayne on most things - I would like to
correct a few mistaken assumptions here.

   The whole idea of the XHDR and "S:" combination is to free the FTP
(user and server BOTH) programs from performing ANY operations
(generation or parsing) on the mail text; so when you say things like
"who says a FTP server must have ANY parser?" all I can reply is
"no, no, that's not what I meant, at all..."

  Let me try to make things clearer about the "assumptions".  I
was keeping in mind both the ITS and TENEX mailing systems, which
seemed to demonstrate the essential requirements.  On ITS the
mail sending (user FTP side) is performed by the centralized mailer
demon itself, which knows everything there is to know about the message;
on the other hand mail receiving comes in via a server FTP which
does nothing at all about either the recipients or the mail text!
Whereas on Tenex, I had the image of queued mail being sent out
by a user-FTP-side program that merely passed the mail text through with
no attempt to understand the contents; this appears to be a
pretty good box-in of the situation, doesn't it?  I can't assume that
either the user or server FTP knows what is going on.

   Thus, the purpose of XHDR is basically to elicit a knee-jerk
reflex from a server FTP, which merely indicates what mail
wizardry the SITE is capable of handling; whether the server itself must
do anything depends on whether the protocol is <ADVANCED>.
Because the "S:" item specifies syntax type within the header itself,
there is nothing the FTP server need do about "marking" - it's already
marked!

  And I agree about the inelegance of tables - that's why XHDR is
there.  But for ease of implementation when most of the world
has the "mail creator" generate the headers separately from the
user-FTP stuff, what else can be done?  There is a big difference
between "ad hoc" tables which you are rightly against, and
"official" tables which everyone can refer to;  I agree that
I should have proposed a NIC table with NIC notification rather
than suggesting a mailing-list.  However, there is still
for the most part no getting around the need for one's own
version of said official tables.  Whether the programs enforce
anything is up to them, but I would sure hate to be sent a header
of type "XYZ" when the official table says my site doesn't know
about that.
   A couple of comments about NIC data.  I am working for the NIC
and have the task of reorganizing, expanding, etc. data bases such as
the host-name list (that file, for one, is obviously inadequate!);
any suggestions for items to include are eagerly welcomed.  Secondly
my own personal viewpoint (not the NIC's) is that most discrepancies
between list and reality happen because the site in question never
bothered to tell anyone.  If they are thereby ignored, whose
fault is that?

I guess that's all I have to say in reply (excepting a PS) since
I don't know how many nits you still have.  If any, send them again. 
I think the counterproposal really would take more work (you may
have overestimated the amount needed for "S:"), is separate from
the issue of specifying syntax/protocol versions, and is not really a
structured protocol - I'd much prefer JFH's 8-bit stuff.  Faster,
easier, no ambiguity & no parsing...  Oh well, I don't care as
long as there is SOME way of gracefully bringing up new
syntax/protocols!!!!!!!!!

--Ken

P.S. Clubbishness.  Most "clubs" are there for excellent reasons.
example: ITS sites have a special socket which allows them to
refer to other ITS sites as pseudo-DSK devices, eg "MC:" is
the same as "DSK: on site MIT-MC".  It works because system calls
and errors can be exchanged directly, and works fast.  There are
many other such protocols all over the network, and they allow
the arpanet to provide a far better level of service than it
otherwise would be forced to, making it much more useful - which is
what I meant.
(the use of an EBCDIC or 32-bit option is as much a "club" as anything
else, by the way.)


Date: 17 NOV 1976 0908-PST
To: Header-People at MIT-MC     
From: Hathaway at AMES-67
Subject: Round Two on XMAIL or whatever

In rebuttal to KLH's rebuttal to my comments on "XHDR" etc: 
 
Sorry, but when you say things like "XHDR ... provides an
optional check for <RANDOM> types" and "the fact will be ob-
vious due to S:" I just naturally visualized the FTP server
doing this checking, since any later would seem to be worth-
less.  But okay, I agree that "S:" eliminates the FTP server
having to do any parsing of text -- exactly as the current
system does not require any parsing of text IF (underlined!)
the "mail receiver" doesn't CARE about header stuff.  If, on
the other hand, the FTP server CARES (like for multiple 
receivers), then kludges like XRCP must be added to extract
that portion of the header that someone at the moment sees a
need for.  All my proposal did was go ahead and extract ALL
of the header stuff and give the FTP server a chance to look
at EVERYTHING without parsing text.  And again, servers that
don't care can either reject XMAIL or just copy it into the
mail file.  
 
I do like your box-in of the situation, one with a smart
mailer and dumb receiver and the other with a dumb mailer
and smart receiver.  Let's hope everybody has as open a mind
on this!  By the way, most of my experience is of course on
my TSS system, which has a dumb sender and a dumb receiver!
But with aspirations you wouldn't believe ...
 
Does "most of the world" really have "the 'mail creator'
generate the headers separately from user-FTP"?  That is a
real question -- on my system it is NOT the case (the user
provides header stuff (other than sender) externally from 
the mail text and the "mail sender" actually generates the
header) and I am curious as to what the real world does.
 
And a great big AMEN! to the distinction between AD HOC
tables and OFFICIAL NIC-maintained tables!  Or I guess I 
should say "table" since I see no real reason for more than
the one we already have.  But about being sent a type XYZ
header when the table said you didn't know about it, it
still makes more sense to me to have the sender ASK ME if
I want type XYZ rather than asking some local or network-
wide table!
 
Methinks you may have opened Pandora's box with your request
for suggestions for additions to the NIC host-name list, but
if you're willing ...  And another great big AMEN! to your
comment about list errors being failure to notify the list
maintainer -- but with N different lists in each of M hosts
will this be any better??????
 
Not sure how much more work my counterproposal would take,
because it is essentially done -- whatever RFC724 defines
(or whatever -- presumably the "KEYWORD: LINE" form will be
used) is simply placed following an XMAIL command.  Tis up
to the server FTP to stuff this junk into the file (or of
course reject XMAIL, in which case we are SIMPLE).  If the
first XMAIL is an "XMAIL S:" line then all required infor-
mation is passed on to the "mail reader" exactly as with
"S:", no?  The problem of specifying recipient address is a
bit of a stickler, but could be handled as indicated by re-
quiring "XMAIL TO:" to be first (with "XMAIL S:" second?).
Seems any remaining nits would be fairly small.  But let me
repeat the one main point of my proposal -- let's take ALL
header information OUT of the mail text and put it where it
is EXPLICITLY available, rather than doing it one item at a
time (e.g., XRCP).  Nuff said ...
 
                                       Wayne
 
PS: (Why is this always a PS?)  I agree completely about all
the neat things that clubs do.  For example, I was really
turned on by the idea of RSEXEC, and wanted to join that 
"joint file system" community and the whole bit.  To date,
however, all I have up is a very buggy RSSER for LINK etc
only.  Why?  Not really lack of time here or anything, but
the fact that all "interesting" protocols (i.e., shared di-
rectories, file transfers, etc) are still defined in terms
of 36-bit numbers, pages, files with holes in them ...  Sure
this club is doing something neat -- how about letting the
rest of the world in?  Not that I'm particularly picking on
RSEXEC, by the way -- Bob Thomas was most helpful and all
that -- just that clubs are great for the members, but can 
be quite bad for others!  (If BBN hadn't implemented RSEXEC
for TENEXs only maybe we'd have a network-standard directory
defined by now.)  And I agree about EBCDIC, and that's the
reason everything relating to EBCDIC should be included in
network standards (e.g., as a TELNET negotiated option or a
well-defined FTP TYPE).  I can't really visualize a club
that I could start which everybody would want to join, but
if such a thing did exist wouldn't it be a bit frustrating
if it were defined ONLY in terms of EBCDIC?
------

Date: 17 NOV 1976 1015-PST
To: Header-People at MIT-MC     
From: Hathaway at AMES-67
Subject: Slight clarification of XMAIL etc

I guess both Ken and I referred to my latest brainstorm as a
"counterproposal" to "XHDR" and "S:".  It is really NOT that
at all, but as pointed out in my rebuttal is really only a
proposal for making header information available EXPLICITLY
as commands rather than IMPLICITLY within message text
(which means available to the mail receiver (FTP server) as
well as to the mail reader).  I guess it is really more an
alternative for XRCP and other commands of that type.  I
think the idea of specific FTP commands for wildly different
syntaxes is fine (XITSMAIL anyone?), as is the idea of
having one standard header item which defines the syntax for
the other items (XMAIL S:).
 
And I also realize that my proposal WILL in fact require a
modification for all FTP users and servers which want to use
anything other than SIMPLE syntax, which Ken's will not.
Again I am more in the XRCP vein.
 
Just wanted to avoid more misunderstandings.
 
                                Cheers,
                                Wayne
------

From:  Stefferud at MIT-Multics
Date:  11/17/76 1612-est
Subject:  May I make a suggestion?
To:  Header-People at MIT-MC

May I make a suggestion?

I have been trying to follow the Header-People discussion and find
considerable difficulty in keeping track of the discussion threads because
of the general lack of antecedant references and the comibining of many
topics in single messages with the SUBJECT: "Ramblings on many things".

This does not help others to follow!

I suggest that Ken Harrenstein fix MIT-MC Header-People broadcaster to
insert an accesion number ssmeplace (maybe even add a new field?) so we can
all refer to easily identifiable messages.

Then I ask you all to break your discussion into separate messages for separate
subjects so that references to specific discussion texts will not require a wwole sentence of description.

The issues we are discussiong are much too complex for this blunderbuss
approach we are taking.

Enjoy, Stef

From:  Stefferud at MIT-Multics
Date:  11/17/76 1628-est
To:  Header-People at MIT-MC

Help, The Multics net_mail system has caught me and I can't find the
bailout button!  Please ignore this while I regroup to say what I wnat to
say!

Sorry boout this!  Stef

From:  Stefferud at MIT-Multics
Date:  11/17/76 1630-est
Subject:  MsgGroup disucssions of "what should a mail handler be?"
To:  Header-People at MIT-MC

Way back in the MsgGroup discussion there are some important messages
that deal with the subject that Wayne raised about "what constitutes
a mail handling system?"  I commend Wayne on his analysis and suggest that
Header People who are not aware of the MsgGroup discussion stuff get apprised
of it before Header People gets drug back through the WHOLE THING.

I will volunteer to dig relevant stuff out of the
[ISI]<MsgGroup>Transactions.MSG file, but those of you with a fancy for
FTP can get a complete survey listing of the contents of that file from
[ISI]<msggroup>Transactions.survey which is in plain text format.

Or perhaps you will be more interested in the [ISI]MsgGroup>proceedings.survey which only lists the "non-administrative" messages.

I don't want to drag all Header People back thourough that stuff, ssnce some
have been there already.

If anyone wants help gettting at any of it, please let me know.  The
transactions file now holds 400 disc pages of text!  All of it has been given
accession numbers so that we can refer to specific mesages with ease.

If you want more info on MsgGroup, please let me know.

Best, Stef

Date: 17 NOV 1976 1704-EST
Sender: MOON5 at MIT-MC
From: MOON5 at MIT-MC (David A. Moon )
To: HEADER-PEOPLE at MIT-MC
Message-ID: <[MIT-MC].15337>

I THINK "<ADVANCED>" PROTOCOLS SHOULD NOT BE PROVIDED FOR
IN FTP, BUT SHOULD INVOLVE AN ICP TO A SEPARATE SOCKET,
SINCE THE ACTUAL SERVER FOR THESE WILL HAVE TO DO "PARSING"
OR SOME KIND OF SPECIAL PROCESSING, MEANING THAT RECEPTION
OF THIS TYPE OF MAIL IS LIKELY TO BE DONE BY A DIFFERENT
PROGRAM THAN THE FTP SERVER.

THE MORAL IS THAT RFC 724 ETC. SHOULD ONLY BE CONCERNED
WITH THE "SIMPLE" AND "RFC724" (NEXT STEP UP, SAME BASIC FORM,
BUT MORE "FEATURES") PROTOCOLS.

P.S. PARDON MY UPPER CASE, WHICH IS PROBABLY CLUBBISH.
I COULDN'T GET TO A REAL TERMINAL TODAY.


From:  Stefferud at MIT-Multics
Date:  11/17/76 1740-est
Subject:  ENVELOPES, LETTERHEADS, CONTENTS, AND MSG HDRS
To:  Header-People at MIT-MC

In the context of Wanynes analysis of the separate functions of the mail
system, i would like to make some vital disctinctions:

  There is a difference between ENVELOPES, LETTER HEADS, AND LETTER CONTENT which we should keep in mind.

I believe that MAILER(FTP et al) should only be concerned with the
envelope and its undamaged delivery.  (Undelayed also would be nice.)

The letter head is not part of the envelope, but it is reasonable to try to
standardize it to some extent, though it is not reasonable to impose
severe restrictions in this regard.

The letter content, we will all agree, is not to be standardized, except that we agree about "watching our language" with "strangers" per someones sage observation, which I cannot cite at this moment.

Back to the envelope:

  It holds the recipeients addresses, the return address(s?), the post marks
  (including the time/date/location stamps of intermediate rerouting stations).

  It does not need to contain the subject or anything ese.

  In fact, in this analogy in TENEX, the envelope is really that "queued"
  mail file called [--unsent-mail--].addressee<atsign>HOST which
  TENEX MAILER deletes after delivering the item via FTP.

  Upon receipt, the postmarks and addresses are generally kept as part of the
  "header" which tends to be a clutter of information that not all recipients
  want to be bothered with.  The header in ARPANET mail systems has become
  an unfortunate combination of "envelope and letterhead."

  The letter head is normally some thing that everyone creates with great care
  to suit himself or his institution.  You may be sure that I was very
  careful to design my Network managemment Associates, Inc. letterhead
  to be exactly what I wanted by way of image projection.

  I don't hold much hope for coming up with a "standard letter head" for all
  ARPANET mail.  I doubt that any of you would seriously consider trying to
  adopt a standard letterhead, given my definition of it!

As for letter content:

  I see you all trying to develop a negotiating protocol for arranging
  for two hosts to establish the fact of being able to comprehend special
  conventions for the format of the contents.

  This is fine with me, if you keep it out of the business of handling
  the envelopes.  There is nothing to stop any of you from setting up
  special protocols for "text composition" systems to negotiate formats
  as long as you agree that this is a protocol level above and outside the
  domain of the mail system.

Nuff for now.  Just wnated to get the issue on the table.  Stef

From:  Stefferud at MIT-Multics
Date:  11/17/76 1753-est
Subject:  Kaaazzzwwwump!
To:  Header-People at MIT-MC

Just gotta comment on the dangers of clubbishness, which this little
community is in danger of collecting on -


It reminds me very much of the GREAT KAAAZZZZUUUUMMP BIRD:

  which flies in a cirlce of diminishing diameter at ever incresaing
speed untill .........

Best, Stef.

Date: 17 NOV 1976 2239-PST
From: STEFFERUD at USC-ISI
Subject: Headers of selected MsgGroup Transactions
To:   Header-People at MIT-MC

The followwng four message headers are taken from
[ISI]<MsgGroup>Transactions.MSG for redistribution to Header-
People at MIT-MC.  The actual messages will follow separately
packaged.  

Upon review, I find that they are not so far out of date as I
would have predicted a year ago when I was constructiong them.
Alas!  Enjoy.  Comments?  Stef 

	
****219! 3059   
Subject: MSGGROUP# 219 MsgGroup Situation Report #1: I. BACKGROUND
From: STEFFERUD at USC-ISI
To:   [ISI]<MsgGroup>Mailing.List:
Date:  2 DEC 1975 2342-PST
Mail from USC-ISI rcvd at 2-DEC-75 2352-PST
********
****220! 3339   
Subject: MSGGROUP# 220 MsgGroup Situatation Report #1: CURRENT SITUATION
From: STEFFERUD at USC-ISI
To:   [ISI]<MsgGroup>Mailing.List:
Date:  3 DEC 1975 2353-PST
Mail from USC-ISI rcvd at 4-DEC-75 0000-PST
********
****224! 4538   
Subject: MSGGROUP# 224 MSGGROUP SITUATION REPORT #1: III. ISSUE MATRIX
From: STEFFERUD at USC-ISI
To: [ISI]<MsgGroup>Mailing.List:
Date: 9 DEC 75 1548-PST
Message-Id: <[FAKE]-4-((76 1 7) (22 30 55) "PST").STEFFERUD>
Reader-Id: 35
********
****227! 3478   
Subject: MSGGROUP# 227 MSGGROUP SITUATION REPORT #1: IV. ISSUE MATRIX 
         SUBCATEGORIES
From: STEFFERUD at USC-ISI
To: [ISI]<MsgGroup>Mailing.List:
Date: 15 DEC 75 2330-PST
Message-Id: <[FAKE]-7-((76 1 7) (22 30 59) "PST").STEFFERUD>
Reader-Id: 38
********
-------

Date: 17 NOV 1976 2240-PST
Sender: STEFFERUD at USC-ISI
Subject: [STEFFERUD at USC-ISI: MSGGROUP# 227MSGGROUP SITUATION REPORT #1: IV. ISSUE MATRIX SUBCATEGOR...]
From: MSGGROUP at USC-ISI
To: header-people at MIT-MC   
Message-ID: <[USC-ISI]17-NOV-76 22:40:43.STEFFERUD>  

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


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


IV.  ISSUE MATRIX SUBCATEGORIES 

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

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

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


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


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


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

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

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

Filing & Retrieval are again more private in nature.  

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

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

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


________ 
-------

          --------------------
End forwarded message
		
-------  

Date: 17 NOV 1976 2243-PST
Sender: STEFFERUD at USC-ISI
Subject: [STEFFERUD at USC-ISI: MSGGROUP# 219 MsgGroup Situation Report #1: I. BACKGROUND]
From: MSGGROUP at USC-ISI
To: header-people at MIT-MC    
Message-ID: <[USC-ISI]17-NOV-76 22:43:04.STEFFERUD>  

	
Begin forwarded message
          --------------------
Mail from USC-ISI rcvd at 2-DEC-75 2352-PST
Date:  2 DEC 1975 2342-PST
From: STEFFERUD at USC-ISI
Subject: MSGGROUP# 219 MsgGroup Situation Report #1: I. BACKGROUND
To:   [ISI]<MsgGroup>Mailing.List:


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

NOVEMBER 18, 1975 

PREPARED BY EINAR STEFFERUD, NETWORK MANAGEMENT ASSOCIATES, Inc.

FOR MSGGROUP 


I.  BACKGROUND 

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

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

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

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

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

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

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

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

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

_ _ _ _ _ _
-------
          --------------------
End forwarded message
		
------- 

Date: 17 NOV 1976 2241-PST
Sender: STEFFERUD at USC-ISI
Subject: [STEFFERUD at USC-ISI: MSGGROUP# 224 MSGGROUP SITUATION REPORT #1: III. ISSUE MATRIX]
From: MSGGROUP at USC-ISI
To: header-people at MIT-MC
Message-ID: <[USC-ISI]17-NOV-76 22:41:39.STEFFERUD>  

	
Begin forwarded message
          --------------------
Reader-Id: 35
Date: 9 DEC 75 1548-PST
From: STEFFERUD at USC-ISI
Subject: MSGGROUP# 224 MSGGROUP SITUATION REPORT #1: III. ISSUE MATRIX
Action-to: [ISI]<MsgGroup>Mailing.List:
Message-Id: <[FAKE]-4-((76 1 7) (22 30 55) "PST").STEFFERUD>


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


III.  THE ISSUE MATRIX 

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

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

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

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

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

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

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

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

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

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


___________ 

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


ISSUE MATRIX (Continued) 

	

	User Activities and Message System Tools


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


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

-------

          --------------------
End forwarded message
		
-------  

Date: 17 NOV 1976 2242-PST
Sender: STEFFERUD at USC-ISI
Subject: [STEFFERUD at USC-ISI: MSGGROUP# 220 MsgGroup Situatation Report #1: CURRENT SITUATION]
From: MSGGROUP at USC-ISI
To: header-people at MIT-MC   
Message-ID: <[USC-ISI]17-NOV-76 22:42:18.STEFFERUD>  

	
Begin forwarded message
          --------------------
Mail from USC-ISI rcvd at 4-DEC-75 0000-PST
Date:  3 DEC 1975 2353-PST
From: STEFFERUD at USC-ISI
Subject: MSGGROUP# 220 MsgGroup Situatation Report #1: CURRENT SITUATION
To:   [ISI]<MsgGroup>Mailing.List:


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


II.  CURRENT MSGGROUP SITUATION 

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

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

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

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

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

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

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

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




_ _ _ _ _ _
-------
          --------------------
End forwarded message
		
------- 

From:  Stefferud at MIT-Multics
Date:  11/18/76 0248-est
Subject:  Clubbing is OK, in its place
To:  Header-People at MIT-MC

Quick, before I am read as being anti all clubs!

I am not.  Specifically because I believe in the need in the net to
cater to the many diverse tastes and stuyles of the potential user/customer
community (market!).  Market segmentation and product diferentialtion are
absolutely unstoppable if we let the network marketplace evolve naturally.

This means that there will be natural clubbing as users band together.
No problem here.

The problem arises only if we tend to make the utility services like netmail
cater to a select subset of the populationg, like only those who can figure
out how to make an upper onlly terminal issue psuedo lowercase,
or only those with 9000 baud glass terminals, etc.

OK?  Stef

Date: 19 NOV 1976 1256-PST
To: Header-People at MIT-MC     
From: Hathaway at AMES-67
Subject: Alternate to "ENVELOPES, LETTERHEAD, and CONTENTS"

I must disagree with Stef's characterizations of ENVELOPES,
LETTERHEADS, and CONTENTS.  For example, the letterhead
really has no parallel in ARPANET mail, since it is a con-
stant item regardless of contents.  Also envelopes are used
only because they are physically required -- I think we 
would all agree that it would be more convenient to just
fold business letters so that the recipient and sender ad-
dresses show and mail them that way.
 
I would propose the alternate characterization of CONTENTS
and OTHER-STUFF (sorry for not being able to think up a
snappier name, but ...).  The definition of CONTENTS should
be obvious -- it's everything from "Dear XXXX" through
"Sincerely YYYY".  The OTHER-STUFF includes all the other
things that get typed on the face of a typical business
letter, including: 
 
         Recipient address
         Sender address
         Date (and time if applicable)
         REPLY TO: 
         IN RE: 
         CC: 
         Encl.
         Special handling instructions (RUSH, ROUTE, etc)
         ATTN: 
         SUBJECT: 
         The author and "clerk" (generally as initials)
         The letterhead itself (which identifies the
                                sending institution)
 
And I am sure several other things.  And one will notice
that all of the above do in fact have corresponding fields
defined in RFC724, right?  Plus several other things more
directly related to "interactive" mail systems (forwarding,
audit trail information, alternate reply addresses, etc).
 
And why are OTHER-STUFF items not simply included within
CONTENTS on business letters?  Usually because they are
important enough to warrant specifying explicitly, so that
they are instantly obvious.  For example, you could include
the line "If you want to reply back to me on this, please
refer to message CD123" but "REPLY TO: CD123" up at the top
sure makes it easier!  As does an isolated "SUBJECT:" or
"IN RE:" or "CC:" or "ATTN:" or whatever.  And that is why
I have proposed that we send CONTENTS over data connections
(which are not scanned at all) and OTHER-STUFF over command
connections (where each one is explicitly available for 
whatever action receivers might like to take, including
rejection of individual lines by otherwise smart servers,
such as "FORWARD TO:").  Sorry to sound like a broken
record, but ...
 
                                       Wayne
------

Date: 19 NOV 1976 1309-PST
To: Header-People at MIT-MC     
From: Hathaway at AMES-67
Subject: A little more clarification ...

On rereading my last note I feel that one thing wasn't made
clear.  There are obviously many things in OTHER-STUFF which
are of interest only in ANSWERING the letter (e.g., "REPLY
TO:"), and these would not normally be of interest to a re-
ceiving FTP.  Many others, however, are of interest at the
time of receipt or delivery (e.g., "ATTN:" or "RUSH") and
these are the ones which should for sure be made available.
I get a "might as well" feeling about making ALL of the
OTHER-STUFF available, although that's admittedly a weak
argument.
 
Also concerning ENVELOPES and such, remember that mail de-
livery in a business environment is much more than what the
Post Office does (which is deliver the envelope unopened to
the receiver's physical location) -- the mail room may open
the letter, handle multiple routings, keep records, time
stamp receipts, and so forth.  It is for this reason, in
fact, that OTHER-STUFF is really specified explicitly, so
that mail handling clerks (server FTP's, anyone?) will not
have to wade through contents.  
 
Nuff said.
                                Wayne
------

From:  Stefferud at MIT-Multics
Date:  11/28/76 0329-est
Subject:  More on ENV/LTRH/CNTNT
To:  Header-People at MIT-MC

Hi,


My purpose in this message is to clarify (hopefully) the ideas that I have
proposed regarding ENVELOPES/LETTERHEADS/CONTENTS.

In answer to Wayne's comments - I agree that there is no current
equivalent to this division in ARPANET messages - and I contend that this is
a big piece of the problem we are trying to solve.  However, it is clear that
a full separation cannot be accomplished for RFC 724.  That must come later.
For RFC 724 we will have to be satisfied with some prose descibing the
ENVELOPE/LETTERHEAD separation, but not much more.

Extension of the idea, it seems to me, involves some of the ideas for
negotiation proceses between processes on the same or different hosts
to establish the formatting and handling protocols to be used to compose
and then interpret the CONTENT and/or the LETTERHEAD to be sent.  To me,
this means that the negotiation protocol is quite valid, but not at the
MAIL FTP level.  Mail must be understood to be a process that delivers
ENVELOPES, without bothering to know what is inside. unless the content is
dangerous to the deliverer or the recipient (maybe).

Next, in the long term it is quite clear to me that we must be given the
privalege, as message or letter composers, of setting up our own distinctive
letterheads, memo forms, etc.  In fact, it is one of the benefits of HERMES
that we can set up formats to suit ourselves.  (Unfortunately, we can't ship
the format infomation along with the text for use by the receiver, (yet!?).

Among some of the HERMES users, we already see special uses of the message
system to set up "project control systems" with message files containing
project status records.  Surely you would not say that all users of ARPANET
mail systems must use "THE STANDARD LETTERHEAD" (or would you?).  I hope not.

So, to sum up, I see the distinction between ENVELOPES, LETTERHEADS, and
CONTENTS to be central to the whole development of the structured mail
concept, which will develop into a hierachy of protocols for establishment
of conventions and agreement on interpretation of the LETTERHEADS and CONTENTS
to be transmitted by our MAILERS of the future.

Best, Stef

S:HANDMADE
Ye-warning: Beware, all feather-footed freaks who dare scan here!
  The Date: 2 days before Xmas, and all thru the ARPAnet...
From-header-person: K(en)L(.)H(arrenstien) at site MIT-MC, 354 octal and
236 decimal and EC hexadecimal and home of MACSYMA and other magical programs which know all about display terminals and suchlike
For: all the nice Header-people
 at MIT-M(acsyma)C(onsortium)
Edited-by: Wonderful ITS TECO & winning macros thereof
Sent-by: Santa COMSAT
delivered-by: all good little FTP servers everywhere
journalized?: no sir
Tertiary-subject: Reindeer byte handling
carbon copy to someone else
		BCC: (wayne may not see this unless...)
ITS-version:1022, MAIL-version:496, COMSAT-version:492
Class: First, with champagne
for-example-to: George Jones' poor sec'y at Host or SHost
Secondary-Subject: none
Reference-number: #LXIX
     <linear-white-space-which-can-clearly-be-ignored>
Primary-subject: 724
final-closing-remarks: Gee, I forgot the message-ID!  See PS.

                 -------------
                 :: MESSAGE ::
Unless I am mistaken, the revised 724 draft was supposed to come
out on the 16th.  Unless it or a status report trickles in
soon, shall I assume that we can all use whatever header we like?
Oh well, merry christmas everyone...

PS: <354105.[MIT-MC]>
Message-ID: See above please

Date:     31 Dec 1976 1608-EST
From:     PHILIP KARLTON at CMU-10A
Subject:  Ma Bell versus the world
To:       Header-People at MIT-MC
Sender:   PHILIP.KARLTON at CMU-10A
Message-ID: [CMU-10A] 322229 PHILIP KARLTON

There is an article of interest concerning the "Bell bill" now in
Congress in the January 1977, issue of Consumer Reports.  If this
bill were to pass (and CU is correct in their comments about the
bill), there would be a tremendous affect on what we can put on our
telephone lines.  I recommend that you read the article.

Phil
-------

Date: 16 FEB 1977 0330-EST
Sender: RMS at MIT-MC
From: RMS at MIT-MC (Richard M. Stallman )
To: HEADER-PEOPLE at MIT-MC
Message-ID: <[MIT-MC].38231>

Hello?

Date: 13 MAR 1977 1750-PST
Sender: FARBER at USC-ISI
Subject: Query
From: FARBER at USC-ISI
To: header-people at MIT-MC
Message-ID: <[USC-ISI]13-MAR-77 17:50:01.FARBER>

Does  anyone  know anything about the availability of a simulator
for the Fairchild F8 microprocessor somewhere on the net?

Dave Farber
-------   

Date: 22 APR 1977 1228-PST
Sender: WALSH at OFFICE-1
Subject: CONTENTS OF SUBJECT FIELDS
From: WALSH at OFFICE-1
To: HEADER-PEOPLE at MIT-MC, MSGGROUP at USC-ISI
Cc: WALSH, STEFFERUD at USC-ISI
Message-ID: <[OFFICE-1]22-APR-77 12:28:26.WALSH>


THIS  IS  JUST  A  COMMENT, INSPIRED BY OUR RECENT PERUSAL OF THE
MSGGROUP AND HEADER-PEOPLE ARCHIVES.  THIS HAS  BEEN  FASCINATING
READING,  AND  THE  INFORMATION  WE HAVE GLEANED WILL BE OF GREAT
HELP IN OUR FUTURE WORK.

HOWEVER, IN THESE FILES OF  MESSAGES,  IT  HAS  OFTEN  BEEN  VERY
DIFFICULT  TO  LOCATE  ALL  THE  MESSAGES ABOUT ITEMS OF INTEREST
WITHOUT ACTUALLY READING EVERY MESSAGE IN THE FILES.  THIS CAN BE
QUITE  A  TASK,  CONSIDERING  THE  450+ MESSAGES IN MSGGROUP, FOR
EXAMPLE.

CONSEQUENTLY, I OFFER THE FOLLOWING SUGGESTION:

IN THESE GROUP-CONFERENCE TYPES OF MESSAGE EXCHANGES,  PAY  CLOSE
ATTENTION TO THE CONTENTS OF THE SUBJECT: FIELD YOU CREATE.  LOOK
AT IT WITH THIS QUERY IN MIND--"WILL THIS MAKE SENSE  TO  SOMEONE
LOOKING AT A LISTING OF MESSAGE HEADERS 6 MONTHS FROM NOW?"

THE "RE:" TYPES OF SUBJECTS WILL BE CLEAR IF THE ORIGINAL MESSAGE
SUBJECT WAS CLEAR; THE ONLY PROBLEM THERE ARISES WHEN  THERE  HAS
BEEN  A  STRING  OF  REPLIES,  EACH  OF  WHICH NESTS THE ORIGINAL
SUBJECT IN ANOTHER LEVEL OF "RE:".

IF YOU ARE ADDING A MESSAGE TO ONE  OF  THESE  CONFERENCE  FILES,
COPYING ONE SOMEONE ELSE HAS SENT YOU, FOR EXAMPLE, USE AN EDITOR
TO CHANGE THE SUBJECT: FIELD IF IT ISN'T CLEAR, OR IS AN IN-GROUP
JOKE.

I  HOPE  THIS  DOESN'T  OFFEND ANYONE; THESE FILES ARE A VALUABLE
INFORMATIONAL RESOURCE, AND I'M JUST LOOKING  TOWARD  MAKING  THE
RETRIEVAL OF THIS INFORMATION AS FAST AND COMPLETE AS POSSIBLE.

REGARDS, WILL MARTIN (WALSH AT OFFICE-1).
-------

Date: 22 APR 1977 1636-PST
Sender: FARBER at USC-ISI
Subject: A reply to msggroup 516
From: FARBER at USC-ISI
To: Walsh at OFFICE-1(Attn: Will_Martin)
Cc: header-people at MIT-MC, 
Cc: [ISI]<MsgGroup>Mailing.List:    
Message-ID: <[USC-ISI]22-APR-77 16:36:49.FARBER>
Keywords: msg516,keywords   

Will, While I think your comments are very appropriate re some of
the rather "interesting" subject fields, there is a field defined
in  message text called KEYWORDS . This field is serviced by some
of the more "advanced" message systems and allows  the  inclusion
of  keywords  ala  CACM.   Perhaps  , in fact, it is necessary to
create and maintain a list of keywords like the ACM and  IEEE  to
allow more organized handling of large message files.

Indeed perhaps some of the more interesting ideas in auto-keyword
generation are worth looking at .

Dave

-------   

Date:     23 Apr 1977 1342-EST
From:     Rick Gumpertz at CMU-10A
Subject:  Time zones
To:       Pogran at MIT-Multics
CC:       Header-People@MIT-MC
Sender:   RICK.GUMPERTZ at CMU-10A
Message-ID: [CMU-10A] 23 Apr 1977 13:42:17 Rick Gumpertz

Ken,

I have noticed that there is a semi-applicable standard for time zone
denotation called "Representations of universal time, local time
differentials, and United States time zone references for information
interchange".  It is ANSI X3.51-1975.  If you have any trouble
finding a copy, I am willing to type the guts of it online.

In any case, it might be appropriate to look at as input to RFC 724.
Unfortunately, it promises another standard for indicating times (as
opposed to time zones) but I can't find that -- maybe it hasn't been
issued yet.

		Peace,
		Rick
-------

Date: 24 Apr 1977 0226-PST
From: TVR at SU-AI (Tovar)
Subject: Keywords 
To:   FARBER at USC-ISI, Header-people at MIT-MC

I would vote against a list of keywords.  The first program at SAIL to
read the news from Associated Press and New York Times used a list of
keywords.  This caused problems, as everyone was requesting that their
keywords be added to the list and an especially irritating problem that
new stories often contain new keywords.  Later automatic keywording and
also suffix removal was done which solved this problem and made the system
more useful in general.  I suspect that this may also be the case in
network mail, as we are (hopefully) often dealing with new ideas.  A
spinoff from the news server is a program called INDEX which makes keyword
index from a ordinary text file which can be accessed by NS (the news
reading program).  Interested persons may want to look at
SUAI:NS.ME[S,DOC], pages 6-9, 29-33.
							--- Tovar

-------

Date:     29 Apr 1977 1612-EST
From:     Philip Karlton at CMU-10A
Subject:  Could FTP error codes be appendix to RFC724
To:       MsgGroup at ISI, Header-People at MIT-MC
Sender:   PHILIP.KARLTON at CMU-10A
Message-ID: [CMU-10A] 29 Apr 1977 16:12:41 Philip Karlton

I have  no desire to hold  up the final version  of this long awaited
RFC, but I do think it would be an advantage to the ARPA community at
large if  some consistency could be coerced accross  sites as to what
the correct error codes are.  It would make the "dumb" FTP's a little
more graceful in handling the return messages if they did not have to
parse  some arbitrary  string to find  out what  happened.  There are
really only three cases:  (a) it worked; (b) it didn't work this time
but if you try again later it might; and (c) this will never work.

I realize that there is some existing standard (I even saw it flashed
accross my face  once about a year ago.) but  there are sites that do
not  adhere  to  it  (including CMU  for  some  cases).   Here  is  a
non-exhaustive  list of failures for  which I would like  to know the
correct code:

        No such user (please don't send this request again)
        Mail transfered correctly (for some ridiculous reason this is
                a different code for MAIL and MLFL)
        Must log in before sending mail (why not send the account and
                password back in  some fixed format on this error and
                then no table of special cases  need be maintained at
                each site)
        No job slots available
        Secondary storage full
        Transfers not allowed during busy time of day
        User exists but is not allowed to recieve mail
        MAIL allowed but not MLFL
        MAIL allowed with no log in but not MLFL with no log in
                (Should there be a difference between MAIL and MLFL?)
        ...

It sure would be nice (from  my point of view anyway) if a site would
just force a local login if  necessary when it gets a mail command if
that is really what it wants.
                        Phil Karlton
-------

Date: 29 APR 1977 1503-PDT
From: POSTEL at USC-ISIB
Subject: Re:  Could FTP error codes be appendix to RFC724
To:   PhilipKarlton at CMU-10A, MsgGroup at ISI,
To:   Header-People at MIT-MC
cc:   POSTEL

In response to the message sent     29 Apr 1977 1612-EST from     Philip Karlton at CMU-10A

to all:

i believe that Phil's request to get out in the open all the really used
responses that ftp servers make to mail requests is valuable. i hope
that the exercise will be carried out as i believe it will lead to more
consistent behavior on the part of the set of mail sending and receiving
programs. for the record i have pulled together the responses the book say
are legal. looking at them there seem to be altogether to many, and a few
seem quite strange. but as i said for the record here they are:

The "official" Protocol (the one in the protocol handbook) lists the 
following responses for the mail and mlfl commands, the commands are 
characterized as follows:
   1xx positive preliminary reply
   2xx positive completion reply
   3xx positive intermediate reply
   4xx transient negative completion reply
   5xx permanent negative completion reply
    
The responses for the MAIL command are:
   250 Requested file action okay; completed.
   354 Start mail input; end with <CR><LF>.<CR><LF>
   421 Service not available
   450 Requested file action not taken: file unavailable
   451 Requested action aborted: local error in processing
   452 Requested action not taken: insufficient storage space in system
   500 Syntax error, command unrecognized
   501 Syntax error in parameters or arguments
   502 Command not implemented
   530 Not logged in
   550 Requested action not taken: file unavailable
   552 Requested file action aborted: exceeded storage allocation
   553 Requested action not taken: file name not allowed
    
The responses for the MLFL command are:
   125 Data connection already open: transfer starting
   150 File status ok; about to open data connection
   226 Closing data connection: requested file action successful
   250 Requested file action okay; completed.
   421 Service not available
   425 Can't open data connection
   426 Connection trouble, closed: transfer aborted
   450 Requested file action not taken: file unavailable
   451 Requested action aborted: local error in processing
   452 Requested action not taken: insufficient storage space in system
   500 Syntax error, command unrecognized
   501 Syntax error in parameters or arguments
   502 Command not implemented
   530 Not logged in
   532 Need account for storing files
   550 Requested action not taken: file unavailable
   552 Requested file action aborted: exceeded storage allocation
   553 Requested action not taken: file name not allowed


--jon.
 
-------

Date:     29 Apr 1977 1858-EST
From:     Rick Gumpertz at CMU-10A
Subject:  FTP reply codes
To:       Karlton@CMU-10A, POSTEL at USC-ISIB
CC:       Header-people@MIT-MC, Stefferud@USC-ISI (for distribution to MsgGroup)
Sender:   RICK.GUMPERTZ at CMU-10A
Message-ID: [CMU-10A] 29 Apr 1977 18:58:11 Rick Gumpertz
In-Reply-To: Your messages of April 29, 1977

Phil, Jon -

It seems to me that the crux of the problem is that noone really
knows what the standard is.  My Protocol Handbook contains two sets
of reply codes.  Beside that, I am repeatedly told that many sites do
not support the "new" (4 year old) FTP.  What we really need is ONE
clear standard, and some checking of who implements it.  Maybe we
should have a published monthly survey of FTP implementations, much
like the old Telnet surveys.

		Peace,
		Rick Gumpertz
-------

Date: 3 MAY 1977 2230-EDT
From: MOON at MIT-MC (David A. Moon )
Subject:  FTP server mail reply codes survey
To: HEADER-PEOPLE at MIT-MC

The following are the codes returned by the ITS ftp server
(MIT-{AI ML DM MC}):
For MAIL
	350 What's shakin?
	450 null recipient
	256 thanks for the blurb
	256 null mail, nothing will be written
	455 file error for name - error message

For MLFL
	402 MLFL only implemented for ascii mode
	255 SOCK nnnnnn
	454 Can't connect to your socket nnnnnn
	505 Type/Byte-size conflict
	250 socket to me
	252 thanks for the blurb
	455 file error for name - error message

Date:  7 May 1977 0054-PDT
From: Geoff at SRI-KA
Subject: What's in a name OR A rose by any other name...
To:   [ISI]<MsgGroup>Mailing.List:
cc:   Network-Liaison-Group:

   We are pretty disgusted with the current flavor of Tenex message
systems, and have decided its time for a brand spanking new one, so
here is your chance for fame, glory, and immortality.  If you have a
fantastic idea(s) for a message system, we'd like to hear about it.
We are also currently looking for a super-winning name to call this
message system.  The only limitation is that it be 6 characters or
fewer so that it will show up nicely in SYSTAT listings.

Your message system name suggestion, and/or ANY and all great ideas
for a message system in the creation process can be sent to:
GEOFF@SRI

We're interested in YOUR ideas....
-------

Date: 13 MAY 1977 2255-EDT
From: MOON at MIT-MC (David A. Moon )
Subject: message forwarded due to misspelled recipient name.
To: HEADER-PEOPLE at MIT-MC

COMSAT@MIT-MC 05/13/77 18:08:28 Re: Msg of 18:08:25
To: NET-ORIGIN at MIT-MC
CC: COMSAT-WIZARD at MIT-MC
WARNING - "HEADERS-PEOPLE" at MIT-MC is an unknown recipient, but
sending will be attempted to [COMMON;HEADER MAIL].
Your message follows, in case you goofed:
-------
Date: 13 MAY 1977 1503-PDT
Sender: CAHCOM at USC-ISI
Subject: Availability of RFC 724:
Subject: Proposed Official Standard for
Subject: the Format of ARPANET Messages
From: Pogran at MIT-Multics, Vittal at BBN-TenexA
From: DCrocker at Rand-Unix, Henderson at BBN-TenexD
To: Headers-People at MIT-MC 
Message-ID: <[USC-ISI]13-MAY-77 15:03:54.DCROCKER>   

RFC  724,  "Proposed  Official  Standard  for  the Format of ARPA
Network Messages", is at last available.  It is  located  in  the
file   [USC-ISIA]<CAHCOM>RFC724.TXT  with  read-access  for  all.
Copies can be retrieved through FTP  by  using  a  user  name  of
ANONYMOUS and your last name as the password.

The file is 82K characters long, which is 39 printed pages.

	
Ken Pogran
John Vittal
Dave Crocker
Austin Henderson
End of HERMES draft
-------   


Date: 14 MAY 1977 0021-EDT
From: MOON at MIT-MC (David A. Moon )
Subject: Comments on RFC 724
To: HEADER-PEOPLE at MIT-MC

0. There are a lot of minor mistakes and typos in the BNF.  For
instance, the syntax suggests "From: foo To: bar" with no crlf is a
legal form of header.  Probably no one will use an automatic parser
generator on it, but it should be corrected before publication anyway.   

1. Note that the rfc defines a way to put a quote mark inside a quoted
string, and a different way to put a parenthesis inside a parenthesized
comment (which is not in the BNF!).  There should be a uniform quoting
convention.  Our mail system uses the convention that slash or
control-Q quotes the following character, always.

2. In section II.C.1.2 it should explain the difference
between a "system entity" and a "generalized person reference".
Also, this section should give a clear and concise statement of
who replies should be sent to.  I can't figure out what it is saying.
An example of what it might say is:
	If a REPLY-TO field is present, send replies to all
	addresses in that field.  Otherwise, send to all addresses
	in the FROM field.  In addition, one may optionally send
	replies also to the addresses in the TO, CC, BCC, and FCC fields.
This is clarified somewhat in the examples, but there's no reason
not to clarify it when it is first introduced.

3. In this rfc, the usual method for enclosing non-machine-readable
text in a recipient name appears to be arbitrary text followed by the
machinable address in angle brackets.  In the current de facto standard
the method appears to be to put the machinable address first, followed
by the arbitrary text in parentheses (this appears to be still allowed
by the rfc.)  If there is a good reason for introducing the new syntax,
which seems more prone to erroneous parsing, it should be included in the
document.

An example of the problems that can occur is a user named
"Jonathon Q. Public, Jr."  If this name appears without enclosing
delimiters, an automatic parser is likely to be confused by
the comma.  (This comes from a real example.)

4. What is the SENDER field for?  Perhaps it is purely for human use,
or perhaps it is for machine use (who to inform if there are errors
in delivery).  The document should say something about this.

5. I'd like to have a way to use names with complicated internal
structure as addressees, for instance:
	From: Moon at MIT-MC
	To: Vittal at BBN-TenexA, [BUG COMSAT (R-OPTION FOOBAR)] at MIT-MC
and have Vittal's reply get to [BUG ...] without confusing the
intervening mail systems.  The proposed standard does not allocate any
characters (such as square brackets) for this.  It's hard to tell from
the BNF, but it appears that I'm not even allowed to use a quoted
string as a machinable arpanet address (reserved for <any-name>). 
There should be a way for one mailer to send its own weird syntax
through a foreign mailer and get it back again intact. 

6. These criticisms should not be taken to mean that I am unhappy that
the mail protocol is finally getting clarified and standardized.  But I
would like to see the document made a little clearer and simpler before
people are told to puzzle out what it is trying to say and implement it.

Date:     16 May 1977 1259-EDT
From:     Rick Gumpertz at CMU-10A
Subject:  RFC 724 and TIME ZONES
To:       Pogran@MIT-Multics
CC:       Header-People@MIT-MC
Sender:   RICK.GUMPERTZ at CMU-10A
Message-ID: [CMU-10A] 16 May 1977 12:59:49 Rick Gumpertz
In-Reply-To: RFC 724

There is an ANSI standard for time zones titled:
        American National Standard X3.51-1975 representations of
        universal time, local time differentials, and United States
        time zone references for information interchange

        (Copyright 1975, American National Standards Institute,
        1430 Broadway, New York, NY 10018)

I see no reason that we should not change our representation to
coincide with that standard.  In particular, they do NOT put a "-"
between the time and the zone, although we could allow that for
compatability.  Also there is no space or anything else between a
time and a "Z".  Finally, they provide an extension mechanism for
unnamed time zones.

Although the standard gives some examples of times, it specifically
says that time (as opposed to time zone) representation is covered in
a yet to be adopted standard.

The changes I propose are:

        <time> ::= <zulu-time> | <zoned-time> | <offset-time>
                        | <old-zoned-time>
        <zulu-time> ::= <24-hour-time> "Z"
        <zoned-time> ::= <24-hour-time> <space> <time-zone>
        <offset-time> ::= <24-hour-time> "+" <offset>
                        | <24-hour-time> "-" <offset>
        <offset> ::= <four decimal digits>
        <old-zoned-time> ::= <24-hour-time> "-" <time-zone>

To help explain <offset-time>, the following equivalences are given:
        1409 EST = 1409-0500 = 1909Z = 1539 NST = 1539-0330
        (2009 in Continental Europe) = 2009+0100 = 1909 GMT
        0809 BST = 0809-1100 = 0809+1300 (The next day)

We should add NST (Newfoundland, offset -0330) and BST/BDT (Bering,
offset -1100/-1000) since they were omitted from the original RFC.
Also note that GDT has appeared nowhere except this RFC -- the
accepted usage is BST (British Summer Time) but, unfortunately, that
is in conflict with Bering Standard Time, which is accepted by the
X3.51.  I therefore propose dropping GDT (and letting people outside
the U.S. use <offset-time> to express local times, until some ISO
version of X3.51 appears).

A note to implementers: <offset-time> can vary from -1200 to +1300,
due to the International Date Line's wandering east from 180 degrees.

By the way, there ought to be a comment in the RFC stating that HST
is also used in Alaska, where it is sometimes called Alaska Standard
Time.  Also there should be a warning to Canadians that their time
zones (e.g. Maritime) are not acceptable.

As an aside, I am confused about the use of white space.  In
particular, if white space is allowed between the parts of
<date-time>, then is it also allowed between the parts of
<24-hour-time>?  The whole issue needs more clarification.

                Peace,
                Rick Gumpertz
-------

Date: 17 MAY 1977 0249-EDT
From: MOON at MIT-MC (David A. Moon )
Subject: This is the second person in a week who can't spell.  O tempora, o mores.
To: HEADER-PEOPLE at MIT-MC

-------
Date:    16 May 1977 1327-EDT
Sender:  RICK.GUMPERTZ at CMU-10A
Subject: previous note on time zones
From:    RICK GUMPERTZ(N810RG02) at CMU-10A 
To:      Header-peopl at MIT-MC

- - - -
I forgot to mention that <offset> may not legally expand to 0000.
Use Z or GMT for that, according to X3.51.  Of course we could
decide to accept +0000 and -0000 offset-times if we wished.

		Rick

-------


Date:    19 May 1977 1347-EDT
Sender:  BRIAN.REID at CMU-10A
Subject: Trailing blanks
From:    BRIAN REID(C410BR10) at CMU-10A 
To:      Header-Peopl  at MIT-MC

- - - -
In searching for a bug in the CMU mailer, I have noticed that TENEX
sites plus some others will reject with a 'NO SUCH MAILBOX...' error
any mail sent to "FOOBAZ " instead of "FOOBAZ", i.e. with a trailing
blank.  This sounds to me like it is incredibly bogus.  Does anyone
know whether or now TENEX sites do in fact have this peculiarity, and
if not, then does anybody have any other ideas about what might be
going wrong here?
			Brian

-------

Date:    19 May 1977 1347-EDT
Sender:  BRIAN.REID at CMU-10A
Subject: Trailing blanks
From:    BRIAN REID(C410BR10) at CMU-10A 
To:      Header-People  at MIT-MC

- - - -
In searching for a bug in the CMU mailer, I have noticed that TENEX
sites plus some others will reject with a 'NO SUCH MAILBOX...' error
any mail sent to "FOOBAZ " instead of "FOOBAZ", i.e. with a trailing
blank.  This sounds to me like it is incredibly bogus.  Does anyone
know whether or now TENEX sites do in fact have this peculiarity, and
if not, then does anybody have any other ideas about what might be
going wrong here?
			Brian

-------


                           

Date: 23 May 1977 1804-PDT
From: POSTEL at USC-ISIE
Subject: Comments on RFC 724
To:   MSGGRP at ISIA, Header-People at MIT-MC
cc:   postel at ISIB


Comments on RFC 724

General Comments:

   Most of the preface and most of section one really turned me off. It 
   seems like someone is trying to score a point some intense war in 
   some very narrow interest group, not a general introduction to the 
   problems in mail systems.  That in fact is just what is really needed
   and would be really useful -- an introduction to the issues of mail 
   systems and a commentary on which are to be attacked by this 
   proposal.  i strongly recommend that section one be replaced in 
   future editions.

   The only real problem currently aflicting the ad hoc arpanet mail 
   system that i percieve (perhaps i don't see clearly enough) is the 
   desire to include people's real names along side their computer 
   mailbox names. This is only a problem when the mail manipulating 
   programs attempt to implement an answer function that derives the 
   destination of the answer from the contents of the header fields. (I 
   like the answer function myself.)  The reason this is a problem is 
   that the de facto reference document (rfc 680) does not speak to this
   inclusion of real names.  This proposal (rfc 724) speaks to much more
   that the current problem so i feel it should more clearly point out 
   the problems it solves (and how it solves them) and the future 
   services it makes possible (and how it does that).

Nitpicks:

   page ii para 3:

      Why is properly in quotes? Does it mean something different than 
      the normal definition?

   page 2 para 3:

      Check the name of this document! It may have more words but the 
      same confusion arises. Lets face it, the title should have the 
      word MAIL in it.

   page 2 para 3:

      I strongly disagree with the notion that rfc 680 was less official
      than rfc 561, and the notion that rfc 680 received poor 
      distribution.

   page 3 para 1:

      Is there a list of mail system implementors that feel justified in
      ignoring rfc 680?

   page 3 para 4:

      Are there references for the "at least two suggestions for a mail 
      transmission protocol"?

   page 4 item 6:

      Why comments in only SOME header items? This sounds like a flaw in
      the specification. (I later learn that some header items are 
      arbitrary strings so comments could not be recognized, but this 
      statement raises a red flag.)

   page 6 sect D:

      The officialness of standards is always a question at every level 
      of at every level of protocol. To my knowledge no arpanet protocol
      at any level has been stamped as official by ARPA. The question of
      official protocols brings up the question of who are the officials
      anyway?  Why should this collection of computer research 
      organizations take orders from anybody?   It is clear that it is 
      in everyones interest to work together and cooperate to evolve the
      best system we can.  Perhaps there is too much emphasis on 
      official and not enough emphasis on best specification so far.  I 
      prefer to view the situation as a kind of step by step evolution, 
      where documents such as rfcs 561, 680, and 724 record the steps.  
      To make a big point of officialness about one step may make it 
      very hard to take the next step.

      Because a set of programs with a generally parallel purpose behave
      in various ways does not prove beyond a reasonable doubt that a 
      document claiming to be a standard specification does not exist.

   page 7 para 3:

      This paragraph is not clear.  Perhaps what it intends to say is 
      the format of the presentation of the specification is not ment to
      implicitly specify things too.

   page 8 para 1:

      The authors hereby take control personally, could the authority be
      vested in the CAHCOM or the NIC?  If a person has an idea for an 
      extension how does she get a hearing?

   page 10 item 2:

      The last sentence of the first paragraph is confused,  i think it 
      should say "The <field-body> may be composed of any ASCII 
      characters (other than <cr> and <lf>, which have not been removed 
      by unfolding). That is, after unfolding there may not be any <cr> 
      or <lf> in a <field-body>."

   page 10 item 3:

      The last sentence is difficult to parse, perhaps it would help to 
      say that <linear-white-space> is equivalent to a single <sp>, and 
      this will be used in the format of this specification document.

   page 11 def of <field-body>:

      The <crlf><linear-white-space-char> is the definition of a fold. I
      would suggest that <fold> be defined explicitly, so as not to 
      confuse. My first reaction was "Ah! This is a fold, and a fold 
      would be removed before i get to analyze this so i will never see 
      this! What is it doing here?"

   page 12 def of <quoted-string>:

      This contains a hidden definition of <">, please pull that out as 
      an explict definition.

   page 12 def of <message-text>:

      typo  "zero of more" ==> "zero or more"

   page 12 def of <comment>:

      How is this different from <text-line>? Is <lf><cr> ok ?

   page 12 defs of misc chars:

      <"> should be defined, as should <null>
      <linear-white-space-char> def refers to an undefined 
      <horizontal-tab>

   page 13 item 3:

      You might want to say that <crlf>s won't be encountered in quoted 
      strings since unfolding will be done prior to syntatic analysis.

   page 14 item 6:

      What is a line? 64, 65, 72, 80, 132, 2000?

   page 15 para 1:

      If multiple instances of the same header item occur, do they have 
      to be adjacent?

   page 16 def of <address-list>:

      What is the implication of a <null> (undefined formal, by the way)
      address list?

   page 17 def of <reference-list>:

      What is the implication of a <null> reference list? This allows a 
      message to contain "References:<cr><lf>" (of course the syntax 
      allows a lot of silly things).

   page 17 def of <day>:

      Why a null day? why not define <date-time> to be
      <day><date><time>| <date><time>

   page 20 item 3:

      Is it clear that such usage is easily separable from computer 
      useable addresses, that is are such addresses distinguishable from
      computer addresses on a syntatic basis?

   page 20 item 4:

      Why not refer to the list of host names kept at the NIC?  Are the 
      alternate names (nicknames) in the NIC list acceptable? Of course 
      the host number is allowed but it will have to be a field 
      partitioned number. See rfc 730.  The NIC list is in the file 
      [Office-1]<NETINFO>HOSTS.TXT at Office-1.

   Page 24 para 3:

      While we may seem slow witted out here on the west coast i contend
      that time progresses at the same rate here as anywhere. I would 
      suggest earlier and later rather than faster and slower.



--jon.
-------

Date: 24 MAY 1977 1000-PDT
From: POSTEL at USC-ISIB
Subject: Comments on Time Zones
To:   MsgGroup at ISIA, Header-People at MIT-MC
cc:   postel at ISIB

i think rick gumpertz comments are well taken, that given the existance of
an ansi standard we ought to conform to that. i would like to point out that
the military has a complete system itself of which Z or zulu time is only a 
small part. in this military time zone scheme each zone is assigned a single
letter code, and Z happens to correspond to what most of us call GMT. so if we
are going to mix schemes perhaps we should do a little homework and do a
complete job.
--jon.
-------

Date: 24 MAY 1977 1000-PDT
From: POSTEL at USC-ISIB
Subject: Comments on Time Zones
To:   MsgGroup at ISIA, Header-People at MIT-MC
cc:   postel at ISIB

i think rick gumpertz comments are well taken, that given the existance of
an ansi standard we ought to conform to that. i would like to point out that
the military has a complete system itself of which Z or zulu time is only a 
small part. in this military time zone scheme each zone is assigned a single
letter code, and Z happens to correspond to what most of us call GMT. so if we
are going to mix schemes perhaps we should do a little homework and do a
complete job.
--jon.
-------

Date:     25 May 1977 1131-EDT
From:     Brian Reid at CMU-10A
Subject:  RFC724 and non-ARPA networks
To:       Pogran at MIT-Multics, MsgGroup at ISI, Header-People at MIT-MC
CC:       Reid@CMU-10A
Sender:   BRIAN.REID at CMU-10A
Message-ID: [CMU-10A] 25 May 1977 11:31:18 Brian Reid
In-Reply-To: RFC724

Even while the packets are buzzing with news about other soon-to-be
networks, and even though many of us are passionately committed to
both personal computing and electronic mail, I don't see any mention
in RFC724 that there might possibly be other networks with which we
would like to interface.

Certainly in a few years, McCarthy's DIALNET or Wilber's PCNET will
be full of users, and I for one would like to be able to send mail to
those people without undue complications.  I envision that there
would be various "portals" between one network and another, and that
mail to an alien host (where "alien" will mean "another network")
would be passed via those portals.

I think that we should make sure that the syntax of mail headers does
not preclude the notion of alien host.  One obvious hack for getting
it in is to encode the entire alien address inside a quoted string,
thereby generating addresses that could be as baroque as

   "Jones at (412) 621-3526 at ZAPNET-Portal" at CMU-10A

which assumes that CMU-10A has a ZAPNET portal, and that "Jones at
(412) 621-3525" is an address on that net.  If ever these other
networks get a more official sanction, to the point where a portal
could be an actual host, then an address of the form

   "Jones at (412) 621-3526" at ZAPNET-Portal

might arise.

There are certainly many pros and cons of this sort of union.  The
addresses could get totally out of hand.  The presence of
other-network portals on the ARPANet could lead to flagrant misuse of
the ARPANet by non-DoD-authorized users, with all sorts of unpleasant
repercussions for.  The other networks may end up in a few years
having so sophisticated a mail system that WE are the orphans.  Who
knows?  But in any event, let's think about it.

			Brian.
-------

Date:     25 May 1977 1234-EDT
From:     Rick Gumpertz at CMU-10A
Subject:  Re: RFC724 and non-ARPA networks
To:       BRIAN.REID at CMU-10A
CC:       Pogran at MIT-Multics, MsgGroup at ISI, Header-People at MIT-MC
Sender:   RICK.GUMPERTZ at CMU-10A
Message-ID: [CMU-10A] 25 May 1977 12:34:45 Rick Gumpertz
In-Reply-To: [CMU-10A] 25 May 1977 11:31:18 Brian Reid

Brian -

It seems to me that one simple solution, for the time being, would be
to allow multiple "at" tokens in an address.  Only the rightmost
would be processed by the ARPANet protocols.  Thus, one could say:
        Gumpertz at funny-host at Gateway
without any quotes or such.  This would send mail to the pseudo-user
"Gumpertz at funny-host" at the host Gateway.

I believe some of the people at PARC are already attacking this
problem with respect to mail which will go into various EtherNets and
such.  Do they have any comments??

                Rick
-------

Date:     25 May 1977 1245-EDT
From:     Brian Reid at CMU-10A
Subject:  Re: RFC724 and non-ARPA networks
To:       Header-People at MIT-MC
Sender:   BRIAN.REID at CMU-10A
Message-ID: [CMU-10A] 25 May 1977 12:45:40 Brian Reid


Begin forwarded message
     - - - - - - - - -
Date: 25 MAY 1977 1231-EDT
From: MACRAK at MIT-MC (Stavros M. Macrakis )
Subject: Internetwork mail.
To: Reid at CMU-10A
CC: MACRAK at MIT-MC

I happened to see in the mail of a local member of the Header-people
a note of yours about internetwork communication.  I have not been
involved in any of this work, but perhaps I can offer a suggestion.

In ARPAnet communication, the path of connection between two users on
different machines is mediated entirely by the network, up to a
point:  it is actually the machines, not the users, that are
connected.  In other networks, perhaps this will not be the case.  In
internetwork communication, it is almost certain not to be the case,
at least initially.

Thus I propose a slight generalization of your scheme: the
"recommended routing".  That is, with the user (who is after all who
you are after-- you shouldn't really care about the machine), you
specify ways to try to get to him.  This makes sense even with the
current net scheme, i.e.  solves the problem "X is either at
Stanford, SRI, or Parc; how do I get him a message without
duplications".  The answer is to send the message to "X" with
recommended routings (Sail, SRI, Parc).  When one tells you that
there is no such user, you try the next possibility.  If at some time
in the future there is an easily-accessible table of addresses for
users, you could either leave off the recommended address or use it,
with the understanding that if it didn't work, the database would be
searched.

This applies just as well to other nets.  It seems likely that other
nets (especially diffuse ones) will connect to ARPAnet at more than
one place:  each of those places may be unreliable (experimental) and
if a node is more than one network jump away, things will be even
more complicated.  Many routings may well be possible.  At some
point, these routings may well be incorporated into (another) network
data base.  Until then, the recommended routings will be useful.

The scheme looks to the future, in interpreting the routings not as
=the correct address= (which currently is often modified by the
receiver--i.e. mail to me at AI, ML, and DM gets forwarded to me at
MC; mail to Bug-Lisp is forwarded to maintainers), but rather as
possibilities to try.  As the network knows more, their importance
will diminish.  And they would work well with ill-defined connected
networks.  I venture to suggest that radio amateurs' networks fall
into this category (of course, ARPAnet is not supposed to support
social conversation, but other networks will explicitly allow it).

I hope to hear your comments on this sometime soon.

Stavros M. Macrakis M.I.T. Research Lab. of Electronics


End forwarded message
-------

Date: 25 MAY 1977 1106-PDT
Sender: DCROCKER at USC-ISI
Subject: Inter-net mailing
From: DCROCKER at USC-ISI
To: Header-People at MIT-MC    
Message-ID: <[USC-ISI]25-MAY-77 11:06:17.DCROCKER>   

I have a feeling that few of you received notice of Jon Postel's
RFC 730, released a couple of days ago.  He reccomends a scheme
for extended addressing.  I also suggest perusing an article by
Carl Sunshine, in SIGCOMM (January, 1977).

Simply stated, the idea is to make <host-indicator> contain path
information of the type that you guys have been suggesting.
(That's Sunshine's recommendation.  Postel's involves more global
naming conventions.)  In either case, the modification to rfc724
is quite simple.  At the time of writing the draft, we did not
have any good ideas for dealing with inter-netting and so we
deferred until someone else did.  Timed-out nicely, I think.

Dave.

P.S.  RFC730 is accessible through ftp at Office-1 and is in file
<netinfo>rfc730.txt.  Use a user name of NICGUEST and a password
of ARPA.
-------

Date: 29 MAY 1977 2231-PDT
Sender: STEFFERUD at USC-ISI
Subject: Multiple deliveries from MsgGroup & Header-People
From: STEFFERUD at USC-ISI
To: Header-People at MIT-MC
Cc: Stefferud
Message-ID: <[USC-ISI]29-MAY-77 22:31:30.STEFFERUD>  

Gentle people of Header People -

II regret to anounce the you are going to be receiving some
multiple copies of stuff that was sent to MsgGroup for further
distribution.  Quite a bit of it in fact.

I have considered editing the MsgGroup list to delete the
multiples, but I don't have a handy list from Header-People.

I am trusting that you will contribute to the work by flushing
aextra coppies with your handy delete buttons.

Actually, one of the main reasons I am not busting my butt to
avoid the replications is because my forwarded copies will
include tthe MsgGroup# for what ever they are worth.

Thank you for your indulgence.  If anyone has a neat solution,
please hand it over promptly.  (Like an edited list that excludes
the duplicates?)

Best, Stef
-------    

From:     Frankston at MIT-Multics (Robert M. Frankston)
Date:     4 June 1977 1523-edt
Subject:  Multiple copy problem. (i.e. msggroup/header-people)
Message-ID:  [MIT-Multics]1.2.BBBJGcZLBwkMWK
To:       stefferud at USC-ISI
cc: msggroup at USC-ISI
cc: header-people at MIT-MC

This is, of couse, an old problem.  If there are many paths
a message can follow it is difficult, if not impossible, to
remove duplicates before the final destination.
Message-ID's are there so that the receiver has an option
to cleanup duplicate copies in his/her mailbox.  I have
taken a step towards this in my own program by flagging such
duplicates. My efforts are limited to those sending systems
that include the message-id.  Perhaps the existence of many
long dupliate messages would provide some incentive for
including the id generally and for upgrading mail reading
programs to purge unwanted copies.

Date: 4 JUN 1977 2330-EDT
From: MOON at MIT-MC (David A. Moon )
Subject: People who can't spell (and non-error-checking mail systems)
To: HEADER-PEOPLE at MIT-MC

-------
Date:    4 Jun 1977 0953-EDT
Sender:  RICK.GUMPERTZ at CMU-10A
Subject: RFC 724
From:    RICK GUMPERTZ(N810RG02) at CMU-10A 
To:      Header-peopl at MIT-MC

- - - -
A couple small nitpicks that have occurred to me on RFC724:

Why hyphenate keywords?  It seems to me that spaces in phrases like
"Reply to" would be much more natural.

Is it OK to have null lists after FROM: and REFERENCES:?  The syntax
would seem to say so.

Nowhere in the syntax does it say that CRLFs are needed (or even
allowed) after <field>s.

Page 21, paragraphh 1, "only if" after a "need not be" makes for a
very strange sounding English construction.  Try leaving out the "and
only if".

Delimeter is an incorrect spelling of delimiter.

		Rick

Date:     8 Jun 1977 1438-EDT
From:     Brian Reid at CMU-10A
Subject:  Re: People who can't spell (and non-error-checking mail systems)
To:       HEADER-PEOPLE at MIT-MC, MOON at MIT-MC (David A. Moon )
Sender:   BRIAN.REID at CMU-10A
Message-ID: [CMU-10A]  8 Jun 1977 14:38:04 Brian Reid
In-Reply-To: Your message of June 4, 1977

CMU has two mail systems, one cruftier than the other.  For some reason
unbeknownst to me, brother Gumpertz used the more crufty one to send you
that message.  It encodes all addresses as two-word SIXBIT strings, which
as we all know limits it to 12 characters in an address.  Header-People
in fact has 13 characters, so our magic MAIL program will throw away the
trailing "e".  I am sending this one using RDMAIL, which has no such
problems (but is 5-6 years newer, so it ought not).
	Brian
-------

Date:  8 Jun 1977 at 1728-PDT
Subject: Re: People who can't spell (and non-error-checking mail systems)
From: Greep at Rand-Unix
To: BRIAN.REID at Cmu-10a
cc: HEADER-PEOPLE at Mit-Mc, David A. Moon(MOON at Mit-Mc)
Message-ID: <[Rand-Unix] 8-Jun-77 17:28:30.Greep>
In-Reply-To: Your Message of 8 Jun 1977 1438-EDT
In-Reply-To: [CMU-10A]  8 Jun 1977 14:38:04 Brian Reid

12 characters?? I hate to think of what it does with names like
CHINESE-FOOD-LOVERS or KNOWN-NETWORK-HACKERS.

Date:     8 Jun 1977 2300-EDT
From:     Brian Reid at CMU-10A
Subject:  Re: People who can't spell (and non-error-checking mail systems)
To:       HEADER-PEOPLE at Mit-Mc, David A. Moon(MOON at Mit-Mc),
To:       Greep at Rand-Unix
Sender:   BRIAN.REID at CMU-10A
Message-ID: [CMU-10A]  8 Jun 1977 23:00:18 Brian Reid
In-Reply-To: <[Rand-Unix] 8-Jun-77 17:28:30.Greep>

Chineese-Foo, obviously.
Look, this program was written in 1971.
-------

Date:     9 Jun 1977 1319-EDT
From:     Brian Reid at CMU-10A
Subject:  Message-ID field
To:       Header-People at MIT-MC
Sender:   BRIAN.REID at CMU-10A
Message-ID: [CMU-10A]  9 Jun 1977 13:19:22 Brian Reid

One of you folks out there had a reasonably passionate explanation of
why Message-ID fields in mail headers are a good idea.  Our mail 
implementor person has said that she would be willing to install it
if I could explain what it was good for.  A whole lot of mail about
message-id fields has rolled by my screen in the past week or so, but
I did not, alas, keep a file copy of any of it.  So, if anybody DID 
keep a file copy, could you forward it to BAJZEK@CMU-10B.  Thanks.
		Brian
-------

Date:  9 JUN 1977 1238-PDT
From: POSTEL at USC-ISIB
Subject: Re:  Message-ID field
To:   BrianReid at CMU-10A, Header-People at MIT-MC
cc:   POSTEL

In response to the message sent     9 Jun 1977 1319-EDT from     Brian Reid at CMU-10A

One use of the message id field is that it provides a (hopefully) unique
reference handle for the message if it ever needs to be cited.  For example
one reference in the references section of RFC 730 cites an arpanet message
from doug wells to me.
--jon.
-------

Date: 10 JUN 1977 0335-EDT
From: KLH at MIT-MC (Ken Harrenstien )
Subject: Message-ID justification
To: Brian.Reid at CMU-10A
CC: HEADER-PEOPLE at MIT-MC

Well, I'm probably who you were thinking of.  My main argument
for the existence of Message-ID's is that they are needed to
prevent endless forwarding loops.  Consider how this mailbox
(Header-people) works; suppose that a similar scheme existed
at CMU; now suppose "Brian.Reid" at CMUA forwarded to Header-people
at MC.  How would you stop this loop without some positive identification
handle?  Note that a loop can be formed of several sites, and stretch
over a period of days if some of these sites are down.
	Such loops have happened amongst the ITS systems.  However,
they are fairly quickly detected by sharp-eyed system hackers,
and are completely "local" to MIT, and relatively infrequent, so the mailers
do not yet actually bother to check the ID.  (and the ID has been removed from
headers in response to user complaints).  I'm afraid it will eventually
have to be reinstated, but hopefully in a more compact form locally.

Date:     10 Jun 1977 1132-EDT
From:     Brian Reid at CMU-10A
Subject:  Message-ID's and forwarding loops
To:       KLH at MIT-MC
CC:       Header-People at MIT-MC
Sender:   BRIAN.REID at CMU-10A
Message-ID: [CMU-10A] 10 Jun 1977 11:32:25 Brian Reid

Ken,

With respect to mail forwarding, I have always felt that a good
approach would be to add a line to the mail header each time it is
forwarded.  Stefferud just recently started putting in a
"Redirected-by:" and a "Redirected-date:" into his mail headers;
locally in my own forwarding at CMU (there is no standard system
forwarding between machines here, so everybody does it himself, and
we all have different ways) I use a "Forwarded-from:" field.  What
this accomplishes is the storing of a forwarding history in the
message text itself; using a Message-id to detect forwarding loops
would require that a whole raft of state information be kept by the
mail delivery routines (e.g., "when has this message-id been through
here before").

	Brian
-------

Date: 10 Jun 1977 at 1852-PDT
Subject: Re:  Message-ID field
From: Greep at Rand-Unix
To: Header-People at Mit-Mc
Message-ID: <[Rand-Unix]10-Jun-77 18:52:59.Greep>
In-Reply-To: Messages of 9 Jun 1977 1319-EDT by Brian Reid at CMU-10A
In-Reply-To: [CMU-10A]  9 Jun 1977 13:19:22 Brian Reid,
In-Reply-To:  9 JUN 1977 1238-PDT by POSTEL at USC-ISIB,
In-Reply-To: 10 JUN 1977 0335-EDT by KLH at MIT-MC (Ken Harrenstien ) and
In-Reply-To: 10 Jun 1977 1132-EDT by Brian Reid at CMU-10A
In-Reply-To: [CMU-10A] 10 Jun 1977 11:32:25 Brian Reid
ATTN: Brian Reid

I always thought the main reason for  message-id's  was  to  help
coordinate  messages  with  other  messages  which relate to them
(mainly replies).  For example if I send a  message  and  keep  a
copy,  and  later receive a reply, my message system can match up
the in-reply-to field of the reply with the message-id  field  of
my  original  message.   That is why the machine-readable part is
supposed to be distinguished by angle brackets.

Date: 11 JUN 1977 2229-EDT
From: MOON at MIT-MC (David A. Moon)
Subject: Message-ID's and forwarding loops
To: HEADER-PEOPLE at MIT-MC

Note that it is perfectly legitimate for a message to pass through the
same host several times.  For instance, if I send a bug report from
mit-mc it will frequently get forwarded to mit-ai where most of the bug
distribution lists are kept, then if one of the users on the list has a
mailbox at mc it could get forwarded back to mc, and that might not be
the end.  One could imagine a message indirecting all over the network
before it finally got to its ultimate recipient (in fact we have done
this for fun.)  The criterion for looping is if it gets sent to the
same recipient-name twice at the same host.  Just putting a forwarding
history in the header isn't good enough.

From:     Frankston at MIT-Multics (Robert M. Frankston)
Date:     12 June 1977 1841-edt
Subject:  message-id
Message-ID:  [MIT-Multics]1.2.BBBJGdFjnnZgKb
To:       bajzek at CMU-10B
cc:       brian.reid at CMU-10A, header-people at MIT-MC

I don't know whetehr my comments can be called
"Passionate", but my basic point is that there is no way to
prevent duplicate messages from finding their way into a
receiver's mailbox since messages may follow different
paths (such as msggroup and header-people) using different
aliases along the way, and even at the destination.  thus
the necessity for a method by which the receiver's mail
program can decide that messages A and B are really the
same messages by two different paths and cleanup the
mailbox without bothering me with  extraneous mail.

KLH@MIT-MC's related comments for mail forwarding systems
also apply in the same way, though it would be, I think,
most reasonable, as a suplement to adding a trailer list to
a letter that can be used to see if the same letter has
been by the forwarder in the past.

From:     Frankston at MIT-Multics (Robert M. Frankston)
Date:     12 June 1977 1850-edt
Subject:  Moon's comment on message ids.
Message-ID:  [MIT-Multics]1.2.BBBJGdFkMmkKdM
To:       header-people at MIT-MC

I agree with Dave Moon that a forwarding center has
problems in eliminating messages. But I still feel they are
the appropriate mechansim for a final destination.

Date:     13 Jun 1977 1223-EDT
From:     Brian Reid at CMU-10A
Subject:  Re: Message-ID's and forwarding loops
To:       MOON at MIT-MC (David A. Moon)
CC:       HEADER-PEOPLE at MIT-MC
Sender:   BRIAN.REID at CMU-10A
Message-ID: [CMU-10A] 13 Jun 1977 12:23:25 Brian Reid
In-Reply-To: Your message of June 11, 1977

Ahh, but if each time a mail server forwards a message, it adds a 
line to the header

	Forwarded-from:	Reid at CMU-10A

(with optional bells and whistles like

	Forwarded-to:	<new-recipient-list>
or	Forwarding-date: 12 June 1977

then it is a simple matter to spot any LOOP in the forwarding,
save for the pathological case wherein a person changes his
forwarding destination during a loop cycle, which would probably
only ever arise via malicious intent.  This scheme cannot eliminate
multiple copies, but it can detect an arbitrarily long loop.

			Brian
-------

From:     Frankston at MIT-Multics (Robert M. Frankston)
Date:     14 June 1977 1010-edt
Subject:  loops, a PS
Message-ID:  [MIT-Multics]1.2.BBBJGdKpJGgZpn
To:       header-people at MIT-MC

Of course, I am assuming that there is a trailer added to
the message and that infite generators of messages or only
nodes within a loop.

From:     Frankston at MIT-Multics (Robert M. Frankston)
Date:     14 June 1977 1008-edt
Subject:  loops
Message-ID:  [MIT-Multics]1.2.BBBJGdKpFLnjgg
To:       header-people at MIT-MC

Perhaps the simplest method of loop handling is the
arbitrarily limit th numer of forwarding nodes through
which a message may go. This is used in file systems to
limit "linking" (or aliasing) depths. It is crude, but
effective.  One can also permit a user to specify a  higher
(but effectively finite) limit for special cases.

Date:     16 Jun 1977 1515-EDT
From:     Brian Reid at CMU-10A
Subject:  Re: loops
To:       header-people at MIT-MC
CC:       Frankston at MIT-Multics (Robert M. Frankston)
Sender:   BRIAN.REID at CMU-10A
Message-ID: [CMU-10A] 16 Jun 1977 15:15:36 Brian Reid
In-Reply-To: [MIT-Multics]1.2.BBBJGdKpFLnjgg

Thereby requiring a

	Times-forwarded:

field??
-------

Date: 16 Jun 1977 1746-PDT
Sender: GEOFF at SRI-KA (Geoff Goodfellow)
Subject: Re:  Re: loops
From: GEOFF at SRI-KA
To: BRIAN.REID at CMU-10A
Cc: header-people at MIT-MC   
Times-Fowarded: 1
Places-Fowarded-Though: MIT-MC
Message-ID: <[SRI-KA]16-Jun-77 17:46:16.GEOFF>
In-Reply-To: [CMU-10A] 16 Jun 1977 15:15:36 Brian Reid 

I certinly hope not!  Thenwe need a 'PLACES-FOWARDED-THOUGH:'
field as well.
-------

RMS@MIT-AI 06/17/77 02:26:16
"Forwarded via" fields need not get in the user's way.
There is no need not to throw them away entirely once the
message gets put into a non-forwarding mailbox.
Therefore, they can't do any harm.  Lets adopt them
as a way of preventing loops.



Date: 29 JUN 1977 1645-EDT
From: EAK at MIT-MC (Earl A. Killian)
To: HEADER-PEOPLE at MIT-MC

Found this on COMMON;HEADER MAIL:

Date:    4 Jun 1977 0953-EDT
Sender:  RICK.GUMPERTZ at CMU-10A
Subject: RFC 724
From:    RICK GUMPERTZ(N810RG02) at CMU-10A 
To:      Header-peopl at MIT-MC

- - - -
A couple small nitpicks that have occurred to me on RFC724:

Why hyphenate keywords?  It seems to me that spaces in phrases like
"Reply to" would be much more natural.

Is it OK to have null lists after FROM: and REFERENCES:?  The syntax
would seem to say so.

Nowhere in the syntax does it say that CRLFs are needed (or even
allowed) after <field>s.

Page 21, paragraphh 1, "only if" after a "need not be" makes for a
very strange sounding English construction.  Try leaving out the "and
only if".

Delimeter is an incorrect spelling of delimiter.

		Rick

-------
^_
Date:    16 May 1977 1327-EDT
Sender:  RICK.GUMPERTZ at CMU-10A
Subject: previous note on time zones
From:    RICK GUMPERTZ(N810RG02) at CMU-10A 
To:      Header-peopl at MIT-MC

- - - -
I forgot to mention that <offset> may not legally expand to 0000.
Use Z or GMT for that, according to X3.51.  Of course we could
decide to accept +0000 and -0000 offset-times if we wished.

		Rick

-------
^_

Date: 29 JUN 1977 1743-EDT
From: MOON at MIT-AI (David A. Moon)
To: header-people at MIT-MC

This message might have been sent already, but I didn't see it so
probably it wasn't.
---
COMSAT@MIT-AI 06/12/77 22:34:01 Re: Msg of 22:33:56
To: TVR at MIT-AI
CC: COMSAT-WIZARD at MIT-AI
WARNING - "HEADER-PEOPLE" at MIT-AI is an unknown recipient, but
sending will be attempted to [COMMON;HEADER MAIL].
Your message follows, in case you goofed:
-------
I've been watching alot of messages go by about Message-ID fields and
I fail to see their absolute necessity.  It seems to me that the composite
of the full date (with time to the second), subject and full sender (i.e.
including host) should work 99.9% of the time and is much easier to refer
to than the Message ID's some systems generate (esp. Multex).  I will
certainly concede that it isn't foolproof (fails if several users are
pretending to be one person for accounting purposes or a messages are being
generated by a program to the same person at >1 per second) but those
systems which are paranoid about it are welcome to checksum the text of
the message.  And the rest of us won't have yet another field to scan
over.

It seems to me a forwarding history might be a good thing to have.  It
gives the user the ability to see this path the message took and take
steps to shorten it (he/she may not know that site X hasn't got his/her
new address).  Before forwarding is done, it could also check to see
if it has already been forwarded to that address and stop it if so.

I apologize in advance if these issues have been already talked into
the ground, as i have trouble keeping up with the messages on this subject.

--- Tovar


From:     Frankston at MIT-Multics (Robert M. Frankston)
Date:     5 July 1977 1104-edt
Subject:  headers
Message-ID:  [MIT-Multics]1.2.BBBJGfqlBCNCqH
To:       ktp at MIT-Multics, crd at MIT-Multics
To:       dmw at MIT-Multics
cc:       pg at MIT-Multics, header-people at MIT-MC

I greatly prefer to send mail with full headers.
Unfortunately, I find that many people greatly prefer naked
laters.  I realize that muchj of the problem stems from the
reader's ignorance of the vast improvement in mail that are
the potential benefits of this hugre amount of cruft typing
out at a slow 30cps.  However, tmany readers of my mail are
not as patient as I am.

In other words when are mail programs going to start
parsing the headers and producing more concise summaries? 
Do any systems do this now?  I know that the homebrew ones
on Multics don't (yet?? please??) and the Multics systems
one is quite obsolete with respect to that developments of
the last decade.

Date: 5 Jul 1977 1104-PDT
Sender: GEOFF at SRI-KA
Subject: Re:  headers
From: Geoff at SRI-KA (Geoffrey S. Goodfellow)
To: Frankston at MIT-MULTICS
Cc: ktp at MIT-MULTICS, crd at MIT-MULTICS, dmw at MIT-MULTICS, 
Cc: pg at MIT-MULTICS, header-people at MIT-MC
Message-ID: <[SRI-KA] 5-Jul-77 11:04:05.GEOFF>
In-Reply-To:  [MIT-Multics]1.2.BBBJGfqlBCNCqH

I myself find that I like the MIT-ITS (SU-AI) style of network
mail headers the best of all when reading mail with your
standardd flavor of mail system that just prints out on your
terminal verbaitum from the message itself.

So far there is only one mailsystem on the network that I am
aware of that provides a way to get around header verbage
problem, and that is BBN HERMES.  It has frobs called TEMPLATES
whereby the user can set up his PTEMPLATE so that you will see
only parts of the message he is interested in, in the order he is
interested in seeing them in.  You are also able to do the same
thing for a survey of message headers, etc.  I personally am
never interested in seeing the MESSAGE-ID or SENDER: fields, so I
just have it omit them when printing up my mail.

The only trouble with this type of mode I fear is that it is a
waste of computer resources; becuase all that extra header info I
am never looking at takes up disk space, and causes the
mailsystem to clank more when you are reading you mail becuase it
has to filter though the entire message and decide what you are
going to see or what you don't want to see.
-------

Date: 6 JUL 1977 0254-EDT
From: DLW at MIT-AI (Daniel L. Weinreb)
To: Header-People at MIT-MC

	The main problem with the system Geoff Goodfellow described is
that when contemplating a proposed network header standard, we cannot
assume that every host has such a hairy mail-reader.  This was
established early in the HEADER-PEOPLE discussion, as some people
complained that the overhead of a hairy header would be too high.  In
fact, throughout the discussion there has been a conflict between the
two viewpoints
	1) I want headers to include (say) "Sender" and "Message-Id" 
	because it allows the mail system to do the right thing, and
	2) I don't want "Sender" and "Message-Id" because it procuces 
	a big, ugly header from which is harder for a person to extract 
	useful information.

	It seems to me that it is fairly easy to distinguish between
those header items which are present because the user would like to see
them, and those only present for the communications system.  But it
has always been assumed that the user must be forced to see the whole
header when he looks at his mail. 
	I think there can be a simple compromise here which could save
a great deal of trouble, and reduce the pain in accomodating both of
these opposing viewpoints.  I propose that all header fields which
exist for the mail system be put at the beginning of the message,
followed by the rest of the header.  The second part of the header
must start with a certain "required" item (for example, the "Date:"
line. 
	What is the effect of this?  Well, for HERMES, there is no
effect at all:  each user can still set up his hairy options and see
whichever parts of the header he wants.  For a system which feels that
a "hairy" mail reader is too high an overhead, all that is needed is a
trivial program to "parse" the header; the program need only look for
the sequence "<newline>Date:" or something to know where to start. I
emphasize that the sofware needed for this is very trivial; any host
which has the hacker power to handle the Arpanet protocols certainly
will find the program a trivial job, and the computer time needed is
"down in the noise." And even if there is someone out there who STILL
cannot do this, he is not in such bad shape at all; the users will see
the message-id's, just as they do now. 

	If you don't like that exactly, you could also put a special 
character in any line of the header which is not meant for the user 
to see.  This too is quite trivial to parse. (Suggested by MOON.)

	Since it appears that any accepted standard will include Message-Ids,
this should only help people, and hurt no one.
	Note that there is no real constraint on mail readers, only on mail
senders in that they must not put anything interesting to users before the
"Date:" field.
		-- Dan Weinreb

PS: If you're wondering who I am, I have recently started to help in maintaining
the AI-ML-MC mail system (COMSAT, etc).


Date:     6 Jul 1977 1125-EDT
From:     Brian Reid at CMU-10A
Subject:  Re: headers
To:       Frankston at MIT-MULTICS, ktp at MIT-MULTICS, crd at MIT-MULTICS,
To:       dmw at MIT-MULTICS, pg at MIT-MULTICS, header-people at MIT-MC
CC:       Geoff at SRI-KA (Geoffrey S. Goodfellow)
Sender:   BRIAN.REID at CMU-10A
Message-ID: [CMU-10A]  6 Jul 1977 11:25:37 Brian Reid
In-Reply-To: <[SRI-KA] 5-Jul-77 11:04:05.GEOFF>

I think that, as usual, everybody is being bit wise and K foolish,
or whatever the transmogrified expression ought to be.  The disk space
to hold a mail header is practically free.  The cpu time to process a
mail header is practically free.  Human time costs money.  At least mine does,
and I am just a mere starving graduate student, worth about as little as
they come in terms of money.

We all (the network mail implementor community) ought to be visionaries,
not bit-niggling misers.  Every single one of us is sending and receiving
mail on a computer much bigger than the one NASA used to put John Glenn
in orbit in that first Mercury capsule, and 5 years from now, when we are
all stuck with foolish little mail programs that worry about a bit here
and a byte there, on machines that make these look like Edsels, may we all
remember how it might have been.
		Brian
-------

Date:  6 Jul 1977 (Wednesday) 1146-Est
From: STECKEL at HARV-10
Subject: sorted fields
To:   header-people at MIT-MC

	DLW's suggestion for sorting fields for the convenience of dumb
message handling programs seems to be one of the better suggestions so far.
I a firmly in category (2) = make mail as simple as possible, but a
simple ordering of required fields would not put a burden on my
nonexistent hacker/staff.  Right now the only information I consider
"interesting" is (1) date (2) subject [less than 1 line, please!]
(3) from (4) to.  The stuff like cc, id, and lefthanded pothooks
is for the convenience of those who have staffs big enough for them.
The ID is certainly useful to prevent multiple copies floating around,
but I really have trouble with long headers on my almost-entirely
CRT based system, and on a hardcopy I get awfully impatient (as do
a lot of users).
	regards,
	Geoff Steckel


Date:     6 Jul 1977 1351-EDT
From:     Rick Gumpertz at CMU-10A
Subject:  Re: sorted fields
To:       STECKEL at HARV-10
CC:       Header-people@MIT-MC
Sender:   RICK.GUMPERTZ at CMU-10A
Message-ID: [CMU-10A]  6 Jul 1977 13:51:49 Rick Gumpertz
In-Reply-To: Your message of July 6, 1977

I agree that the sorted fields are reasonable, given that a standard
sorting can be agreed upon.  Personally I like the extra information, but
am willing to make trivial concessions to dumb programs.

		Rick
-------

Date: 6 Jul 1977 1134-PDT
Sender: GEOFF at SRI-KA
Subject: Re:  Re: headers
From: GEOFF at SRI-KA
To: BRIAN.REID at CMU-10A
Cc: Frankston at MIT-MULTICS, ktp at MIT-MULTICS, 
Cc: crd at MIT-MULTICS, dmw at MIT-MULTICS, pg at MIT-MULTICS, 
Cc: header-people at MIT-MC
Message-ID: <[SRI-KA] 6-Jul-77 11:34:34.GEOFF>
In-Reply-To: [CMU-10A]  6 Jul 1977 11:25:37 Brian Reid

I think you are being a bit wise and K foolish or whatever the
transmorgrified expression ought to be.

When you look at systems like ISI, BBN, SRI-KA, etc, where the
MAJORITY of the entire system is for the express purpose of
people mananging their electronic mail over the ARPANET, then you
know how expensive it really is.  When you recieve and send 30 to
70 messages a day average, then what you 'consider' free is
rather expensive.  Not all systems have unlimited disk space you
know.  And it is not true at all about time to process a mail
header is free - maybe that is so on a KL-10, when when you are
on a KA you can darn well feel it when the loag avg is roaring.

 I say that it is absolutly rediculas for BBN HERMES to do what
it does now as far as the TEMPLATE business, and I wish there was
a way I could turn off sending the MESSAGE-ID and SENDER fields
in outgoing mail, but it seems the BBN HERMES people back at BBN
are stuck in their ways, and refuse to make that an option.

There was a good message fowwarded around the MSGGROUP sometime
ago from McKenzie at BBN whereby he said he couldn't afford t use
new fnagled mailsystems like HERMES or MSG becuase of the
overhead they took, but just to type his mail file out in whole
and then flush ir or rename it.

If you think I'm going over the deep end a bit - I invite you to
try taking care of your mail for a week or month with HERMES and
see what I am talking about.  Bells, Whistels and Frills are
never 'free' - at least as long as I have been around.

[Geoff]
-------

Date: 6 Jul 1977 1145-PDT
Sender: GEOFF at SRI-KA
Subject: Re: sorted fields
From: GEOFF at SRI-KA
To: STECKEL at HARV-10
Cc: header-people at MIT-MC
Message-ID: <[SRI-KA] 6-Jul-77 11:45:15.GEOFF>
In-Reply-To: Your message of July 6, 1977

I think that sounds like a nifty idea too -- but again one of the
nice things about the HERMES mailsystem is that you can have the
stuff like the CC, ID, or whateverelse come after the message, so
you can always ^O it if you are not interested in seeing it; but
since most of us to now have such new fangled frobs and whizmos
in their mailsystem like this, i think the Sorting Fields would
be the best win.
-------

Date:     6 Jul 1977 1353-EDT
From:     Rick Gumpertz at CMU-10A
Subject:  Brian's comments on Bit-picking
To:       BRIAN.REID at CMU-10A
CC:       Header-people@CMU-10A
Sender:   RICK.GUMPERTZ at CMU-10A
Message-ID: [CMU-10A]  6 Jul 1977 13:53:34 Rick Gumpertz
In-Reply-To: [CMU-10A] 6 Jul 1977 11:25:37 Brian Reid

Right on!
-------

Date:     6 Jul 1977 1753-EDT
From:     Brian Reid at CMU-10A
Subject:  Headers
To:       Geoff at SRI-KA, Header-People at MIT-MC
CC:       Frankston at MIT-Multics, KTP at MIT-Multics, CRD at MIT-Multics,
CC:       DMW at MIT-Multics, PG at MIT-Multics
Sender:   BRIAN.REID at CMU-10A
Message-ID: [CMU-10A]  6 Jul 1977 17:53:58 Brian Reid
In-Reply-To: Geoff's message of July 6, 1977

Geoff,

I seem to have drawn your ire, for which I apologize; further, it
probably detracted from the readability of my message.  Let me
elaborate on my previous comments.

I believe that it is not worthwhile to point fingers to try to
isolate resource-wasters, but I am nevertheless going to jump in and
do it anyhow.  Let me offer TENEX as an example; I'm sure that
MULTICS would also serve, but I don't know enough about it to
comment.

CMU has two KA-10's and one KL-10.  We run them under TOPS-10,
primarily for reasons of efficiency.  I very much prefer TENEX, but
must agree with one of our local systems people who described it as
"the best single-user system in existence, but when you add a second
user, the overhead will kill you." He has a point, if one believes
that CPU cycles and disk blocks are the fundamental units of value.
TENEX trades computer time for human time, by providing power at the
expense of efficiency.

I could go to Senator Proxmire, the government's famous efficiency
watchdog, and present him with ironclad evidence that the ARPAnet is
wasting scandalous amounts of money by running a big slow clunky
system like TENEX when it could be running a little austere system
like TOPS-10 and do the same amount of computing with half as many
computers.  I would not be lying if I told him that, but I would be
misleading him, since we all know that TENEX has many virtues other
than efficiency.

All of us computer-science folks realize that TENEX is a step forward
and not a step backward from TOPS-10, but we would have a great deal
of difficulty proving as much to a congressional investigating
committee, who could easily be convinced that TENEX was another B-1.

I won't even stop here.  I am going to assert, not to a congressman
but to you, that the problem with HERMES is not HERMES but TENEX.  In
support of this assertion, I submit that CMU's mail program, RDMAIL,
which I did not write and therefore feel free to brag about, can do
anything HERMES can do and much more.  RDMAIL's user community now
encompasses probably 80% of CMU's mail users, and those who don't use
it are primarily just old-timers who have never learned how to use
such a newfangled piece of software.  And RDMAIL is efficient.  On
our KL-10 or our KA-10s, RDMAIL is fast enough that one sustains no
noticeable overhead and very little measurable overhead by using it
instead of the monitor command TYPE.

Please don't get me wrong.  I am not suggesting that TENEX be
abandoned or that everybody should start using our RDMAIL program
instead of their own.  No.  I wish that we had TENEX here, but I
recognize that the price we would have to pay for it would be a
dramatically increased response time.

Whatever standard is adopted for network mail headers, it will be
around to haunt us for a long time.  Preliminary standards have a
very bad habit of becoming petrified into permanent ones long after
they should by rights have been abandoned.  Other networks are being
built, and they will very likely adopt compatible formats.  Faster
computers will be built, and bigger disks connected to them.

Let's now talk about efficiency, not in terms of "whodunnit"
finger-pointing, or in terms of futuristic expectations of what
computers will do ten years from now, but with numbers and with
today's computers.

The mail header in the message that you sent me looked like this:

	Date: 6 Jul 1977 1134-PDT
	Sender: GEOFF at SRI-KA
	Subject: Re:  Re: headers
	From: GEOFF at SRI-KA
	To: BRIAN.REID at CMU-10A
	Cc: Frankston at MIT-MULTICS, ktp at MIT-MULTICS,
	Cc: crd at MIT-MULTICS, dmw at MIT-MULTICS, pg at MIT-MULTICS,
	Cc: header-people at MIT-MC
	Message-ID: <[SRI-KA] 6-Jul-77 11:34:34.GEOFF>
	In-Reply-To: [CMU-10A] 6 Jul 1977 11:25:37 Brian Reid 

I
removed from that header the so-called spurious fields, collapsed a
double blank or two into a single blank, and came up with this:

	Date: 6 Jul 1977 1134-PDT
	Subject: Re: Re: headers
	From: GEOFF at SRI-KA
	To: BRIAN.REID at CMU-10A
	CC: Frankston at MIT-Multics, KTP at MIT-Multics,
	CC: CRD at MIT-Multics, DMW at MIT-Multics, PG at MIT-Multics,
	CC: header-people at MIT-MC 

My mail-reading program tells me that the large header has 406
characters and the small header has 276 characters, a difference of
130.  Now let's look at the body of the message.  I won't include it
in this text, but my mail-reading program says that it is 1985
characters long.  Those 130 characters, then, represent 6.5% of the
message size.

I recognize that the header will be a larger percentage of shorter
messages, but I have no statistics on the size of the average
message.  Looking through my own mail archives, in which I have a
summary of all of the mail I have sent or received in the last three
years, I find that there are records of about 20,000 messages sent
and received (exclusive of multiple copies, and including purely
local non-network mail), which collectively took about 1,200,000
characters.  This would indicate an average message size of 600
characters, of which the 130 characters represent about 22%.  Not all
of those messages had "In-reply-to" fields, so I would like to revise
that figure down to 20%.

I don't believe that a 20% difference is worth fighting about.
Computer speed per unit dollar has been almost doubling every year
for the past 15 years.  Secondary-storage capacities per unit dollar
have been increasing 43% per year over the same period (C.G. Bell's
figures).  Now, industry trends aren't going to make your KA-10 run
any faster, but I think we would be incredibly short-sighted to
design a protocol that will have its hands tied against future
expansion to save 20% of the overhead on a computer that is already
obsolete.
-------

Date: 7 JUL 1977 0029-EDT
From: DLW at MIT-AI (Daniel L. Weinreb)
To: header-people at MIT-MC

	1) Re: Brian Reid's message of 6 JUL 77 1125-EDT.  I agree that hairy
mail readers are nice; I use one myself and would be seriously hampered if it
were to go away.  But I still don't think it is reasonable for us to assume
that every host does/should have a hairy mail reader.  I won't contend you on
grounds of efficiency, but I do know that it is a reasonably non-trivial effort
to WRITE a hairy mail reader.  We certainly cannot assume that everyone can 
afford the hacker power for that, although maybe they should be encouraged.

	2) Re: Geoff Goodfellow's message of 6 JUL 77 1134-PDT:  Two things:
First of all, I cannot seriously belive that you think my (quote) Parsing
(unquote) program would EVER add up to a significant amount of computer time.
I am quite familiar with KA-10's (I am on one right now) and I KNOW that that
program is trivial and fast.
But secondly, please clarify:  Are you contending that because on your system
(and ISI, BBN, whichever) "... the MAJORITY of the entire system is for the
express purpose of people reading their electronic mail" that therefore the
mail reader program should be kept MINIMAL?  It would seem to me that the
exact opposite is true; such a system should place very high priority on
making mail as easy and painless as possible.

	3) Re: Geoff Goodfellow's message of 6-JUL-77 1145-PDT: Well, with my
proposed scheme HERMES could STILL put the message ID at the end.  I'm not
stopping them; my scheme has no effect at all on hairy readers.  It simply
makes things easier for those who don't HAVE hairy readers.

P.S.  Please don't keep CCing messages to those Multics people; they
are getting two copies of everything, which is sort of annoying...


Date: 7 JUL 1977 0312-EDT
From: MOON at MIT-MC (David A. Moon)
Subject: This brouhaha about headers
To: HEADER-PEOPLE at MIT-MC

We have long wanted to make our mail system understand headers, and reap
all the (alleged) benefits.  However, there is one big problem.  The people
at MIT-DMS have been trying to parse headers for years, and as best I know
their experience has been that it is IMPOSSIBLE, because every single host
on the network sends a different format of header.  It is long past time
that some effective standards got generated.

RFC 714 (or whatever the number was) is supposed to address this, but
besides introducing a lot of complicated new features, it doesn't fully
address some issues which need to be addressed for a usable standard. 
I'll mention some but not all of these.

One is that simple programs need to be able to show simple uncluttered
messages to (simple?) people.  Dan's proposal yesterday seems like the best
solution to this and should be in the standard.

Some mail system on Tenex puts "CC: Name" rather than "CC: Name at Site"
in the header when "Site" is the site originating the mail.  This is one
example out of hundreds of non standard recipient names (and happens to
be my pet one to bitch about).  I don't know if the RFC is sufficiently
specific to say whether this is legal or illegal; I seem to remember that
it is not.

We will never be able to have programs understand message headers
(except maybe one or two very hairy and buggy programs) unless almost
every site sends a rigidly defined well understood standard format, and
this apparently isn't ever going to happen unless the standard is
SIMPLE.  (Look at the past few years of experience.)

So, I don't know, I guess I'll just go on only reading my mail if I'm
on a fast display terminal and have time to ignore most of it.

As long as I'm sending bits all over the world I might mention my
surprise at the use of Tops-10 as a paragon of efficiency.  I've never
used Tenex, so maybe it's even worse, but I've used Tops-10 quite a bit
and it has always been unbelievably bletcherously slow, especially for
anything having to do with files.  Multics performs very much better
with double the number of users, less processor power, and quite a bit
more memory, for whatever that shows.  (The fact that the vendor
charges 5 times as much for the same amount of hardware is
[ir]relevant.)

From:     Frankston at MIT-Multics (Robert M. Frankston)
Date:     6 July 1977 1310-edt
Subject:  headers
Message-ID:  [MIT-Multics]1.2.BBBJGfzZbxnnxk
To:       header-people at MIT-MC

here we go on another long round of discussions

1. DLW's suggestion still requires changing mail sending
programs. While it might be argued that this is less
intrusive than asking all readers to change, it is still
beyond the capailbities of many debudgeted projects.

2. As the annoyances visible to the reader are the cause of
much of the unhappiness, attacking the problem at that
point may be more effective.

3. It is presumptuous of the sender to determine what is
important.

4. DLW's still require the reader be modified to take
advantage of the new feature.

5. The virtue of the suggestion is that it is simple to
modified the reader for the parsing.  A possible compromise
on a similar level of program is for the reader to
(optionally) discard all lines begging with "to:", "cc:",
"date:, "message-id:". Or, alternatively accept only
desired fields.  This can be builtin or table driven.  One
problem is that I think (without checking into it) that the
continuation scheme of RFC 724 is hairy. It should be
possib le (and currently seems to be in all headers that
fly by me) to parse by taking all text, excluding spaces,
from the newline to the ":" and looking up the keyword in a
table.

6. Damn it, maybe I'll just fix a copy of the Multics
program for myself and those who wish to share it since I
get my complaints from local users.

From:     Frankston at MIT-Multics (Robert M. Frankston)
Date:     7 July 1977 0316-edt
Subject:  cheap quick and dirty.
Message-ID:  [MIT-Multics]1.2.BBBJGgBxlmjlgL
To:       header-people at MIT-MC

I agree with Moon's comment that a standard must be simple
if it is to be implemented.  This is especially true when
many variations on a defacto standard in daily operation
exists and no one has the time or money to replace it.

To repeat a point I made earlier, I don't think that the
degree of parsing I am asking for is difficult and it is no
more complicated than processing DLW's sorted header since
one would have to open the mail program anyway to implement
it and will have to parse the first word of the header
lines.

For each line read in until the first null line or the
first line without a colon or some such trivial
determination of the end of the header:

a. buffer the first n (16?) character upto a ":".  ignore
those after n until the ":".  Fold the case o fthe
characters so buffered.

b. When the ":" is found, compare the characters to a table
of keywords that can be builtin to the program. These
keywords can either be used for exclusion or inclusion of
the line for typing on the terminal. (i.e., exclude: "cc",
"to", "message-id", "in-reply-to" but print the rest or
print only "from", "date" and "subject").   Note that 16
characters is even extravagent.  For the purposes of this
table, just four characters should be sufficient allowing
assembly language programs to do word lookups.

c. print or skip to the next newline.

That is all I am asking for.  I don't really care that it
is not perfect and will not parse the variations of tenex
headers nor reorder the fields acording to the user's
whims.  It will stop people from bitching to me about 10
line headers for one line messages and maybe convince
pepople that headers aren't simply evil plots against them.
 And this shuld be very CHEAP, a trivial extension to a
PRINT (i.e. TYPE) command!!!

Of course, I'd still prefer to read my mail on a fast
terminal because of 100 line replies to my simple pleas.

Date:     7 Jul 1977 1032-EDT
From:     Brian Reid at CMU-10A
Subject:  Simplicity (but not Butterick)
To:       Header-People at MIT-MC
Sender:   BRIAN.REID at CMU-10A
Message-ID: [CMU-10A]  7 Jul 1977 10:32:19 Brian Reid

It is truly unfortunate, but inevitably true, that simple headers
must be the norm or else we will never have a norm.  Think how awful
it would be if there were this much disagreement on the format of
the network packets.  Any standard, even a bad standard, has got to
be good at this point.
-------

Date:    7 Jul 1977 1058-EDT
Sender:  BRIAN.REID at CMU-10B
Subject: CMU mailer and 12-character names
From:    BRIAN REID(A800BR10) at CMU-10B 
To:      Header-People at MIT-MC

- - - -
Our mailer has been allegedly fixed to allow long mailee names.  But
we haven't tested it yet.  This is a test.  If you don't get this
mail, please let us know.

-------

Date:  7 Jul 1977 1018-PDT
From: Feinler at SRI-KL
Subject: RE:  "If you don't get this mail, please let us know"
To:   brian.reid at CMU-10B
cc:   feinler, header-people at MIT-MC

I got the mail and I'm not letting you know.

Jake

???????????  I think I am going squirrely !
-------

Date: 8 JUL 1977 0340-EDT
From: MOON at MIT-MC (David A. Moon)
To: HEADER-PEOPLE at MIT-MC

	Date:     7 Jul 1977 1226-EDT
	From:     Philip Karlton at CMU-10A
	Subject:  Re: This brouhaha about headers
	To:       MOON at MIT-MC (David A. Moon)
	Sender:   PHILIP.KARLTON at CMU-10A
	Message-ID: [CMU-10A]  7 Jul 1977 12:26:01 Philip Karlton
	In-Reply-To: Your message of July 7, 1977
	
	It is not impossible to parse headers most of the time.  After about a week
	of staring at the headers coming in and some discussions with people that
	new something about headers and a little negotiation with one especially
	objectional site, I managed to get RDMAIL to parse all the headers that my
	users see.  (At least I am not getting complaints about that part of the
	program.)  The "Name" instead of "Name at Site" problem can be handled by
	assuming that any bare name is at the site of the sender of the message.
	
					PK
-------
Well, maybe it's not as bad as it used to be, perhaps we'll try something.

Of course, all such problems (bare ccs) can be handled by simple
patches to the code, but once you've handled all the problems, the
program gets enormous and people like Geoff complain that they can't do
anything without waiting half an hour, and it gets bletcherous and
impossible to maintain. 

By the way, does the line of seven hyphens in the middle of this message
screw up anyone's mail reader?  Should RFC724 say anything about this?
Do you deserve to lose?

Date:  8 Jul 1977 0937-EDT
From: JHAVERTY at BBN-TENEXE
Subject: Header Parsing
To:   header-people at MIT-MC

As an interested bystander, maybe I can relate some of
the problems which HAVE occurred in parsing mail headers over
the years.  The issue of names and site association should be
enough to give the flavor of the problem:

1/ I don't know what a survey would show now, but it is the case
that sites in general do not always follow the rule that 'naked'
addressees are the sending site.  At one point, phrases of the
form "A, B, C at Some-Host" implied that A and B were associated
with Some-Host, not necessarily the host of the sender.  This
requires some kind of table in the parser, to store the info about
which convention the site uses.  Its worse than that however, because
sites can, and do, have several mail-sending programs, which may
not be consistent, and the conventions used seem to change
as each new mail-system maintainer 'fixes' the system.  Top
this off with the ability of random users to edit
the fields at will, and the result is a parser that gets the right
answer 'most' of the time.  But try to explain to users why
some of their mail gets missent.

2/ The parser cannot reeliably determine
which site the header came from.  Should it take the site, if any,
expressed in the Sender field, if any?  Not very reliable.  Should
it take the site from which the message was received by FTP. Also,
not reliable -- witness the MC forwarding service.

3/ When you start allowing forwarding of messages, what then?
Some forwarding commands copy the parts of the original header
into the encappsulating header.  So, knowing which site, or
even sender, sent a message does not guarantee
that the header was generated by that site's conventions.

A standard MIGHT solve the problem.  The above should
indicate that the standard is not a simple one, especially if
you try to achieve a compromise between exactness
and verbosity.  Even with a standard, parsing will be unreliable
unless the standard is enforced -- i.e. users aren't allowed
to change the headers.  What results is a mail system which
works 99% of the time (optimistically), and will sooner or
later scatter some relatively important message to the ends of
the earth.

4/ I forgot one -- how do you handle a reply-to, when the
TO field contains something like the sender's name for
a distribution-list file?  Sending the reply to that addressee
will often not work.  E.G. [ISI]<POSTEL>Message.Group.Distribution ...

Hope this provides some food for thought.

				Jack
-------

Date:     8 Jul 1977 1141-EDT
From:     Brian Reid at CMU-10A
Subject:  Parsing fields
To:       Karlton at CMUA
CC:       Header-People at MIT-MC
Sender:   BRIAN.REID at CMU-10A
Message-ID: [CMU-10A]  8 Jul 1977 11:41:05 Brian Reid
In-Reply-To: Your message of July 8, 1977

Actually, Philip, I have found a few cases in which RDMAIL failed to
parse headers (e.g. mail from SU-AI wherein the TO:  field needs more
than one line).  But I think the reason that it works is that it is a
new product, written after the mail header formats became stabilized.
David Moon probably tried to do his parser a long time ago, and I can
easily understand why he gave up.

I have been mulling over a fairly radical idea about network mail for
several months now.  I may as well put it forward.  I think that it
is too radical to ever actually be implemented, but I may as well
toss it out for comment.

I was thinking about the interesting contrast between the total
uniformity of the Host-Imp communications, and the rigorous
specifications of the contents of the actual packets, in contrast to
the total ununiformity of the mail headers that get sent as data over
those packets.  A possible path to uniformity, not necessarily on the
ARPAnet but maybe on future ventures, would be to carry the header
information not in the "user data" part of the imp packets, but in
some coded field.  The act of sending a piece of mail would involve
the sending host exchanging information with its imp, telling the imp
the value of the "sender" and "to" and "message-id" fields.  Once
having performed this initialization, the sending host would then
just ship out a normal ascii message text.  If the sending host chose
to put the header information in its ascii text, that would be its
own business; if the sending host chose to punt all that to the imp,
that would also be its own business.  At the receiving end, the
receiving host and the receiving imp could negotiate the exchange of
that information.

An interesting side-effect of this method is that it would allow a
given host to be "certified" as being safe from forgeable mail.  If
the host-to-imp negotiations at the sending end were in the operating
system and not in a user program, and if that part of the operating
system could be certified correct, then assuming that the network
itself were safe from tampering, then sites could rely on mail from
the certified host to be secure.

	Brian
-------

Date:     8 Jul 1977 2013-EDT
From:     Rick Gumpertz at CMU-10A
Subject:  Re: Parsing fields
To:       BRIAN.REID at CMU-10A
CC:       Header-People at MIT-MC
Sender:   RICK.GUMPERTZ at CMU-10A
Message-ID: [CMU-10A]  8 Jul 1977 20:13:07 Rick Gumpertz
In-Reply-To: [CMU-10A] 8 Jul 1977 11:41:05 Brian Reid

Hog wash.  The IMP has no business in such a high level protocol.  The lowest
you shold possibly consider is HOST-HOST protocol.  (I think that is
too low as well).

		Rick
-------

Date: 8 JUL 1977 2021-EDT
From: DLW at MIT-AI (Daniel L. Weinreb)
Subject: Headers
To: Frankston at MIT-MULTICS
CC: Header-People at MIT-MC

	Bob, it becomes apparent that you didn't understand what I
said at all.  For example,you said:  

    1. DLW's suggestion still requires changing mail sending
    programs. While it might be argued that this is less
    intrusive than asking all readers to change, it is still
    beyond the capailbities of many debudgeted projects.

What are you talking about?  The whole point of Header-People is to 
figure out what headers should be doing, and then CHANGE THE SENDERS!
Heave you been paying attention for the last year?

    2. As the annoyances visible to the reader are the cause of
    much of the unhappiness, attacking the problem at that
    point may be more effective.

  That is precisely the point at which I AM attacking it.  Are you
awake? 

    3. It is presumptuous of the sender to determine what is
    important.

	The SENDER won't determine it, the Network Standard Protocol
will, and I think it is quite clear which items go in which classes.

    4. DLW's still require the reader be modified to take
    advantage of the new feature.

	Well, of course, that's what the whole letter is about.
If this is an objection, please say what the problem is.

	The schemes you then proceeded to describe were not very complicated,
but they were complicated enough that I can see many people being turned off
by them.  The idea of my proposal is that it is SO simple that no one can 
reasonably worry about its complexity at all.
	Sorry for generating all this noise, everyone -- I really thought
I was taking pains to make myself clear the first time so that I wouldn't need
to do this sort of thing...  --dlw


From:     Frankston at MIT-Multics (Robert M. Frankston)
Date:     8 July 1977 2356-edt
Subject:  headers and readers
Message-ID:  [MIT-Multics]1.2.BBBJGgHgbwqClg
To:       dlw at MIT-MC
cc:       header-people at MIT-MC


0. I notice that your letter did not have a message-id,
makes it hard for my readers to identify the two copies I
got as being duplicates. I want to have all the cruft
available in the header so my reader can determie the
Redundancy.

1. I agree that the idea of header-people includes changing
the mail senders. However, I assume it also includes
possible modification fto all mail handling programs that
must deal with headers.  As  a matter of fact it has become
the dumping ground for many random comments on mail that
should perhaps be in msggroup. My point is that it seems as
though we have to change the readers in any case. 
Furthermore one has the option of changing one's own
reader.  Changing senders requires another level of effort.
Furthermore changing senders requires changing all senders,
an unlikely prospect. It is the readers who are getting
annoyed.

2. we agree about the poor readers.

3. The degree of complexity of the scheme I outlined is
debatable. I find it much simpler than modifying the
senders to sort fields. Furthermore, I don't think the
network protocols should go around telling me what I want
to read.  It should be restricted to what information
should be available for mail programs to function
effectively and should leave to to me to decide if *"to" is
more or less important than "date".  Admittedly my proposal
compromises and leaves it up to the local system hacker,
perhaps a poor choice.

In anycase, my aim was to inspire those who can modify
their mail reading programs to do so. To repeat my main
point:  This is a change that can be made to mail reading
programs locally without interacting with any other mail
programs on the network given the assumption that most
headers appear in the relatively standard form that we are
now accstomed to.

Date: 9 JUL 1977 2320-EDT
From: DLW at MIT-AI (Daniel L. Weinreb)
Subject: headers and readers
To: Frankston at MIT-MULTICS
CC: Header-People at MIT-MC

	I will try to keep this reply short so that everyone won't 
have to endure more arguing.  It seems your main point is that
hairy readers are a good thing, and require only local modifications.
Fine, I agree.  But some people have made it clear that they do not
plan to implement hairy readers, and the header standard cannot
assume that the receiving end has as hairy a reader as you are talking
about.
	As for your other points:
0) We are not putting our message-id's into the headers because KLH 
commented out the code to do that.  I don't know why.
1) If the rest of us were as fatalistic as you, and all believed
that we cannot change all senders, then we might as well give up and go home.
I am not that fatalistic.
2) There is no "SORTING" involved!  All you have to do is write the code
which generates headers IN A SPECIFIC SEQUENCE, that's all!  As for not wanting
"network protocols not going around telling you what is interesting,"
you are quite free to read the whole header, or write your own hairy reader.

Several of the rest of the sentences in your letter are irrelevant, so
I won't bother to say anything about them.   --dlw


Date:     10 Jul 1977 1254-EDT
From:     Brian Reid at CMU-10A
Subject:  Hairy mail readers and bletcherous operating systems
To:       Frankston at MIT-MULTICS, Header-People at MIT-MC
Sender:   BRIAN.REID at CMU-10A
Message-ID: [CMU-10A] 10 Jul 1977 12:54:32 Brian Reid

I have heard complaints from TENEX and MULTICS sites that hairy
mail readers cost too much, and I have heard comments that TOPS-10
is too bletcherous (I like that word, whichever of you it was who
first started using it) and too inefficient.  I don't have a copy
of the Header-People mailing list, so I don't know if there are
any other non-MULTICS non-TENEX sites out there with hairy mail
readers.  I know that GREEP at RAND-UNIX has one that is reputed
to be mighty classy.  Do non-TENEX non-MULTICS users share this
feeling that hairy mail readers are impossibly expensive?
		Brian
-------

From:     Frankston at MIT-Multics (Robert M. Frankston)
Date:     10 July 1977 1625-edt
Subject:  Hairy mail readers
Message-ID:  [MIT-Multics]1.2.BBBJGgMqMgGjnL
To:       BRIAN.REID at CMU-10a
cc:       header-people at MIT-MC

Who on Multics has complained that "hairy" mail readers
cost too much?

From:     Frankston at MIT-Multics (Robert M. Frankston)
Date:     1 August 1977 0230-edt
Subject:  message system survey
Message-ID:  [MIT-Multics]1.2.BBBJGhzkpWQDmZ
To:       msggroup at USC-ISI
To:       header-people at MIT-MC
cc:       Stefferud at USC-ISI

With respect to rfc724 adoption/rejection and with respect
to general happenings it seems worthwhile to ask who is
currently making significant changes to message processing
programs.  In particular, is anyone implementing programs to
conform to rfc724 exact and "rfc724-like" protocols.

Date:  1 AUG 1977 0852-PDT
To: Header-People at MIT-MC
From: Hathaway at AMES-67
Subject: Message system survey response

The AMES-67 response to the message system survey:  No, we are
not currently doing anything about RFC724.  Part of the reason
for this is lack of time and peoplepower, but most of the
reason is dissatisfaction with RFC724 and the whole mess.
 
The header format debate has been going on for an incredible
amount of time and has gone full circle at least three times,
but still there is no generally acceptable standard.  And
frankly RFC724 was quite disappointing to me, having missed
several of the points which seemed to have been agreed on in
discussions.  And I guess I am getting just a bit tired of all
the rather silly things that have been flying around of late,
with the suggestion that the IMP's handle message headers
being the crowning idiocy that made me essentially give up
hope that anything useful will ever come out of this group.
 
I guess I hope that I am wrong, but ...
 
Wayne Hathaway
------

Date: 1 Aug 1977 0856-PDT
From: MRC at SU-AI (Mark Crispin)
To:   Hathaway at AMES-67, Header-People at MIT-MC   

I agree with Hathaway that mail headers have gone too far, in fact I
thought that long ago.  What ever happened to nice SHORT headers that
stopped at Date:, From:, and Subject: lines???

-------

Date:     1 Aug 1977 1217-EDT
From:     Brian Reid at CMU-10A
Subject:  Re: Message system survey response
To:       Hathaway at AMES-67
CC:       Header-People at MIT-MC
Sender:   BRIAN.REID at CMU-10A
Message-ID: [CMU-10A]  1 Aug 1977 12:17:48 Brian Reid
In-Reply-To: Your message of August 1, 1977

Oh, come on, Wayne.

Not for a moment was I trying realistically to suggest that IMPs
handle message headers; rather, that in some future network with
different protocols and different boundary lines between the
communication hardware (e.g. IMP) and the host, that might be a good
place to put them.  The very fact that this group has in 3 years of
bickering not come up with anything even remotely close to pleasing
the whole group suggests to me that there is something basically
wrong with the approach or with the basic assumptions.

Remember the detective in "The Purloined Letter" who was called in by
Scotland Yard to find the letter after their people had failed,
explaining to the prefect why he was not going to bother duplicating
their search: if Scotland Yard, the best detectives around, had
failed to find it, then the problem must be not with the search but
with the basic assumptions motivating the search.  Along those lines,
my train of thought was that if this group, surely as good a bunch of
systems people as can be found, fails to come to an agreement after 3
years of dickering, then perhaps there is something wrong with the
basic assumptions that we are working with, rather than with the
details of the dickering.

I can see both sides in the "Do we or don't we RFC724" argument.  On
one hand, any form of standardization is better than none at all, and
RFC724 is better than nothing.  On the other hand, as Picasso was
fond of saying, "the good is the enemy of the best":  RFC724 is just
good enough to lull us all out of looking for the ideal protocols,
which it seems not to be, and if we adopt it we will most likely be
stuck with it for years.

CMU seems to be drifting towards an RFC724-like format, but we aren't
there yet and may in fact never be.

		Brian
-------

Date: 1 Aug 1977 1951-PDT
From: MRC at SU-AI (Mark Crispin)
Subject: mail headers
To:   Reid at CMU-10A  

C'mon now.  Really, CMU's mailer is one of the most guilty of overly
verbose headers (along with Multix, MIT-DMS, and BBN).  Most users do
not want to see all that garbage, and particularly when the message is
shorter than the flaming header!

All you are doing with this header hairiness is to encourage users to
write programs to censor their incoming mail and remove the junk from
the headers.  I know the CIA likes the message ID, but for real people
that junk is meaningless, as are the silly things like the sender and
the in-reply-to and forwarded-from and all that other junk.

Now, for MY ideas as to what a header needs:

	A date/time of sending (moderately useful)
	ID of sender (one line, at the worst something like
		MRC at SU-AI (Mark Crispin) but no more)
	Optional subject line
	Optional carbon copy list, should be omitted if no carbon copies
		(including carbon copies to the sender, so if MRC sends a
		 CC to himself it should not be displayed)
	Body of message

Anything more than that is extraneous and an unnecessary burden on my
time to have to parse and ignore it.  Fortunately, a few systems have
maintained their senses and others (like MIT-AI/ML/MC) are slowly regaining
theirs and going back to simple headers.

Hairy mail reading programs are fine and good.  I use several myself on
different hosts.  But all these programs need to do is to keep an archive
of old mail for future reference, and to allow mail reply/forwarding/etc.,
and the list of what a header needs above is more than enough (more than
enough, since the date/time are not needed).

Believe it or not, most people do not pay attention to the "In response to
your message of ...." since few people remember what they were doing at the
exact time, and usually judge their correspondence out of context.  I send
enough mail daily to overflow my capacity to remember each message.  What I
generally do in replying to mail are:

	1.  My favorite mail reading program uses the subject of the received
	    message as the subject in my reply.

	2.  I also insert the sender's mail into my message, and suitably edit
	    it so that I am not merely echoing back the sender's message with
	    a reply but am responding to specific points in the message, and
	    including those points only when necessary in context.

One reason I can do this is that this mail reading program is actually a
function of a display text editor.  I understand that users at CMU and Tenex
sites must use non-display mail reading programs such as CMU's RDMAIL and
Tenex's MSG which cannot provide those facilities nearly as well (the best
MSG can do is get you into a printing-console text editor such as printing-
console TECO, I am not as sure of RDMAIL).  But that does not mean that
because of an individual system's limitations all users should be subjected
to such crocks.  Hell, we'd still be using line-at-a-time EBCDIC and IBM 2741
terminals if that were the case!!

-------

                         

From:     Frankston at MIT-Multics (Robert M. Frankston)
Date:     2 August 1977 0314-edt
Subject:  around and around we go .................
Message-ID:  [MIT-Multics]1.2.BBBJGjDNmklMXN
To:       mrc at SU-AI
cc:       header-people at MIT-MC

I have received a letter from MRC at SAIL (Mark Crispin)
complaining that all we want are simple letters with little
information.  I don't know why I got it since only Reid at
CMU is on the distribution list.  BUt I assume that some
benevolance (sp?) on the Net has seen fit to drop it into my
mailbox.

Mark complains that complicated headers are unwanted and are
interfering with user's seeing simple messages.  I agree
that this can be the case. However Mark, says that the
desire to see simple headers has forced the receiver of mail
to selectively print header fields and discard uninteresting
ones.  yes yes yes, that is precisely what I think they are
supposed to do.  Not as a desperate measure   as  MRC seems
to imply, but as a correct and appropriate reponse to the
problem of meeting the needs ofa given reader.



However, he then says that some systems have "come to their 
sense" by refusing to include header lines  he deems
extraneous! This is precisely the wrong approach to  the
problem and simply has the effect of preventng the growt of
message systems  by not providing information that systems
can and do use.  I will not repeat the rationale behind the
individual fields, but will say that I at least would like
the opportunity to choose the ones I want.

The place for censorship is at home.  For the publisher to
perform cesorship is a fundamental mistake, at least in this
instance.

Ps: I apologize for gross typos but my keyboard is flaking
out on me.

PPS: If people did not
get MRC's message, I'll forward a copy to header-people.

Date:     2 Aug 1977 1026-EDT
From:     Brian Reid at CMU-10A
Subject:  Re: around and around we go .................
To:       Header-People@MIT-MC
Sender:   BRIAN.REID at CMU-10A
Message-ID: [CMU-10A]  2 Aug 1977 10:26:09 Brian Reid
In-Reply-To: [MIT-Multics]1.2.BBBJGjDNmklMXN

I forwarded Mark Crispin's msg to Header-People; everybody should
have a copy.

Mark: do you also leave return addresses and zip codes off your USPS
envelopes?  They can also be construed as being superfluous.

-------

Date:     2 Aug 1977 1112-EDT
From:     Brian Reid at CMU-10A
Reply-To: Header-People at MIT-MC
Subject:  Further ruminations on why we are fighting so much
To:       Header-People at MIT-MC
Sender:   BRIAN.REID at CMU-10A
Message-ID: [CMU-10A]  2 Aug 1977 11:12:59 Brian Reid

I have been meditating about why these unending fights over message
headers seem to slosh around the net like forwarding loops, with the
same things being said over and over again.  I have come up with a
couple of ideas, and ask your opinion.  Perhaps if I make it
controversial enough we could have something else to fight about, but
alas, questions of 'why' are seldom controversial.

It seems to me that the basic problem is that different folks have
different ideas as to just what a "message" is.  At one end of the
spectrum, some people seem to believe that a message is an ASCII file
(or EBCDIC, for our friends who use Brand I), conceptually no
different from a program source.  At the other end, believers seem to
feel that a message is an instantiation of some abstract data type,
whose current implementation lamentably looks enough like an ASCII
text file to encourage the unwashed to treat it like one.  And
various people seem to take various intermediate positions within.  I
will confess to being of the "abstract data type" camp; I would no
sooner think of reading a message with a text editor just because it
was in ASCII than I would think of trying to edit a .REL file with
TECO.  (I'm sure that somewhere on this vast and wonderful net, some
hacker has got a version of TECO that will edit rel files)

Now, given that each of us has a mental picture of just what a
message is, and given that each of us is a seasoned hacker, confident
of his ability to make sound judgments about systems and formats and
programs, these fights seem to boil down to people getting upset when
some proposal doesn't mesh with their notion of a message.

Consider the case of rel files.  We don't go shipping them around the
net, because the information that they contain is too
monitor-specific, but that's not relevant.  A rel file, on every
system that I have ever seen, is a file with a special internal
format, designed to be written by special programs and read by
special programs.  Nobody seems to feel that it is unfortunate that
rel files are not compatible with their favorite editor, and nobody
ever complains about the vast amount of header information in a rel
file.  And the reason is that people are in agreement that a rel file
is a special object, deserving special treatment.

Some operating systems encourage the "data type" concept in files by
providing nice monitor-level tools to enforce it.  Others, such as
the TOPS-10 monitor here at CMU, have this stone-age notion that a
file is just a sequence of characters (unless it is a binary file, in
which case it is a sequence of words), and that any program able to
read and write those characters should be allowed to.  And I suspect
that the image people have of what a "message" is depends in part on
the ability of their favorite operating system to support more
abstract notions like typed files.  I know that my own image of
strong typing in files comes from my background as a (bletch) Exec-8
hacker on Univac systems, and I see around CMU people's notions of
weak typing or no typing coming from their having grown up on
TOPS-10.

So let's fight about this for a while.  What is a message?  Should
the network protocol for message transfer attempt to kowtow to
individual sites' ideas of what a message is?

	my usual verbose self,
		Brian
-------

Date: 2 Aug 1977 0908-PDT
From: MRC at SU-AI (Mark Crispin)
Subject: return addresses
To:   Reid at CMU-10A, Header-People at MIT-MC  

I put return addresses on my mail.  As for network mail, simply
"From: MRC at SU-AI" is enough, although adding "(Mark Crispin)" is alright
for us humans, especially since initials are (in my opinion) a loathsome way
to refer to a person.  I don't see where the other 5 lines saying more or less
the same thing help much.  All I care about is where to reply to the sender,
and perhaps what is his/her/its name in the "real" world.  Granted the message
ID helps the CIA file network mail easier, although considering how incompetant
those guys have been I don't think much can help them.

As for US mail, I can perhaps see a date where zip codes will be the way US
mail will be identified as to location and city/state will be obsolete.  Which
would be a shame; since zip codes are sadly lacking in personality.  However,
since the US mail system will be out of business before that happens, I don't
think we need to worry about that.  But that is all the more reason for network
mail to be usable!

And with that humorous(?) note, I hope this chapter is over.  From what I've
heard, Header-People are in two camps, the people who like long hairy headers
and the people who loathe long hairy headers.  I think I have indicated I'm one
of the latter.

-------

Date:  2 AUG 1977 1134-PDT
To: Header-People at MIT-MC
From: Hathaway at AMES-67
Subject: "What is a message?"

Since Brian made the mistake of asking my opinion ...
 
To me a message is information exchanged between two parties.  It is
what appears in a message between "Dear Foo" and "Sincerely, Bar".
(We all know about the love affair that has been going on between Foo
and Bar for years ...)  All of the other junk is there for reasons
such as delivery of the information, indication of where it came from
(to avoid having to read the bottom of the letter first) and when,
how to reply, the sentiments of the sender (remember upside-down
stamps from your High School summer romance days?), and a multitude
of other extraneous stuff.  But the MESSAGE itself is simply the
information being exchanged (and by the way, if Foo and Bar were to
happen to be programs, the "message" may well be a dreaded rel file).
 
Which brings me back to one of my proposals of last year:  how come
we are so adamant about including all this other junk with the actual
message itself, rather than using the FTP command connection?  We
surely don't indicate that a data file being transferred is ASCII by
inluding a "FILE-TYPE: ASCII" line in the data stream itself;  we
instead use a separate FTP command saying "TYPE A".  So how come
we include stuff like "TO:" and "SUBJECT:" and all that other junk
in a message data stream?  My proposal:  simply define one or more
new FTP commands to specify all that, so that the mail receiver/
deliverer (the server FTP process) can see it and act on it without
having to parse a data stream.  Or it can simply write the commands
verbatim into the mail file (giving exactly what we currently have).
Or it can choose to totally ignore all such lines, including perhaps
a short header of its own.  But whatever its choice, it can do it
WITHOUT PARSING A DATA STREAM!
 
And a couple of comments to support this suggestion.  Why send 73
copies of the message to Host X simply because there are 73 people
(mailboxes) there receiving carbons?  How about having the mail
receiver (server FTP) make the multiple copies for you?  (I know
this is beyond the scope of what we are currently considering, but
I just wanted to point out that there is really no reason we should
copy the way USPS mail is handled;  we've got COMPUTERS in the loop,
dammit, let them compute!)  And a devil's advocate question:  does
anybody's mail receiver check for a discrepancy between the parameter
on the FTP "MAIL" or "MLFL" command and the parameter of the "TO:"
line in the header?  It seems that everybody accepts the need for a
recipient name on "MAIL" or "MLFL" (to create mail files under the
right account, for example) but nobody accepts similar needs for
other header information (to allow multiple addressees or copies,
to allow priority delivery, etc.).  Basically, I feel that the mail
RECEIVER (server FTP) should at least have the opportunity to do
special things based on header information;  if it chooses to pass
that responsibility off to a mail READER then so be it.
 
And by the way, Brian, we are discussing mail HEADERS, not message
transfer in general (I think?).  The only question is really how
you pass extra information along WITH the message text.
 
And one finalness:  In Mark Crispin's last note he laments the
possible use of ZIP code instead of city/state as "sadly lacking
in personality."  This is quite reminiscent of the argument against
a universal serial number (Social Security Number or whatever) --
which is to me totally ridiculous!  There may be hundreds or even
thousands of Wayne Hathaway's in the world, but dammit, there's
only ONE with my serial number!  How can you possibly be more
personal than that?
 
And tis time to end the filibuster ...
 
WH
(456-68-8721)
------

To:  Whom it may concern ...
From:  Old pain-in-the-ass at AMES-67
Subject:  My earlier query about MAIL versus TO
You received this message through HEADER-PEOPLE.  I was just
illustrating that the TO: line is not the most useful thing
in the world.

Cheers!    Wayne Hathaway

Date:  2 AUG 1977 1209-PDT
To: Header-People at MIT-MC
From: Hathaway at AMES-67
Subject: Further on MAIL versus TO:

On further thinking about my comment on discrepancy between the
MAIL param and the TO: param, I realize that they are often
DELIBERATELY different, as when mail is forwarded through the
Header-People file.  It seems more aesthetic that I should see
 
         To:  Hathaway at AMES-67
         Forwarded-from:  Header-People at MIT-MC
 
rather than the current scheme, though, no?
 
Anyway, I've made my spike in the net traffic statistics for today ...
 
WH
------

Date:     2 Aug 1977 1456-EDT
From:     Richard M. Nixon at LEAVENWORTH
Subject:  Integrity of mail headers and presidents
To:       The huddled masses
Sender:   Rose Marie Woods

Let me make one thing perfectly clear---that mail headers are only as
honest as the people who use them.  With MIT-MC to launder mail the
way Mexicans can launder money, this scheme will work every time.

		Dick

RMN/BR10@CMUA
-------

                              

Date: 2 AUG 1977 1316-PDT
Sender: DCROCKER at USC-ISI
Subject: Re:  Further ruminations on why we are fighting so much
Subject: What is a Message?
From: DCROCKER at USC-ISI
To: BRIAN.REID at CMU-10A
Cc: Header-People at MIT-MC 
Message-ID: <[USC-ISI] 2-AUG-77 13:16:22.DCROCKER>
In-Reply-To: [CMU-10A]  2 Aug 1977 11:12:59 Brian Reid  

Thank you.  Thank you.  Thank you.  I have been getting
increasingly frustrated at what I felt to be some sophomoric
thinking and could not think of a constructive way to respond.
Your suggested focus can be quite useful and I will hereby
contribute my version of "what a message is", although I should
warn you that it has nothing to do with computers:

A message is a communication act between people and/or
organizations.  It usually is part of an ongoing communication
process; many such processes are similar but many others are
quite idiosyncratic.  Since the "message" is fundamental to the
process, it is necessary that it be constructed in a way that is
optimal for the PARTICULAR process in which it is used.

RFC724 (and the like) attempt to provide a framework for
transmitting messages of various constructions (but based upon a
standard, computer-and-human processABLE extensible data type, of
the object-attribute-value variety).  Standards are inherently
sub-optimal when applied to any particular and complex situation,
so it is not surprising that 724 is fraught with problems.  Its
one advantage is how little it REQUIRES of participants.

Yes, I really said "little".  In most of the wailing that has
passed across my screen, few if any of you have distinguished
between the requirements of the standard (existing and proposed)
and the ways in which those standards are currently being used by
particular systems.  Those complaints also manage to be
remarkably egocentric, given that this is supposed to be a
research community developing some new technology.  Not too
surprisingly, we do not yet understand that technology
adequately, so of course we are not using it as properly as we
all would like.  Arpanet mail is approximately 5 years old.
Compare that to to the developmental state of assorted other
complex technologies and you may find that we are doing better
than the norm; but, then, we are not yet using our new toy in as
sophisticated ways as we are going to.  Before calling for less
robust standards, I suggest that some of you think a bit about
the communication requirements for typical offices and then
imagine replacing all of the paper-based, and some of the
telephone-based, parts with computer-based mail.  We are not even
close to being robust enough for that situation.  And 724 is not
the right framework for getting there; it is intended to respond
to more immediate and DEMONSTRATED needs.  Most of what has been
complained about in this forum has also been hailed by other
users.  Before you claim that various features are useless, you
had better offer a rationale other than the simple fact that you
don't like them.

Before saying any more, I had better substantiate my claim that
most complaints should be directed at message creation software
(including the one I designed at Rand) and not (for the most
part) at RFC724 and its associates:

RFC724 requires a date field and an originator field.  No other
fields are required by the standard.  The former can be formatted
in various ways, tho not enough ways to account for everyone's
style.  One could argue that we should have been either more
restrictive or more permissive in that, but it is a fairly minor
point.  The "originator field" may actually be as many as three
fields, due to the ways mail has ALREADY been used on the
ArpaNet.  I should note that those with the most substantive
criticisms to 724 seem most pleased with this particular aspect
of the standard.  In the simplest case, the originator field can
be "From:  DCrocker at ISI" or, somewhat more pleasantly:  "From:
Dave Crocker <DCrocker@ISI>".  So if you really want to keep your
messages simple, the standard certainly allows you to.

But of course the new hairy message systems do not keep things
simple and you could quite reasonably suggest that they are being
applied inappropriately for the PARTICULAR communication
processes in which some of us participate.  We may disagree about
particular situations and particular simplifications, but the
ensuing discussion would likely be considerably more constructive
than most of what has been passing by over the last year.

                        Your obedient servant,

                                Dave


-------   

Date:     2 Aug 1977 2143-EDT
From:     Brian Reid at CMU-10A
Subject:  Lower and lower
To:       Header-People at MIT-MC
Sender:   BRIAN.REID at CMU-10A
Message-ID: [CMU-10A]  2 Aug 1977 21:43:32 Brian Reid


Begin forwarded message
     - - - - - - - - -
Date: 2 Aug 1977 1637-PDT
From: MRC at SU-AI (Mark Crispin)
Subject: what is a message
To:   Reid at CMU-10A  

I have always understood a message as being something for my convenience,
not for the convenience of some machine.

If messages are really for computers, why not have a computer program read my
mail and answer it without having to bother me with even seeing it at all??

Oh well.  I also do not like file typing or any other such unnecessary
restrictions on what I can do with a file.  If I choose to have a hairy mail
reading program, fine, but I don't want to inconvenience myself; it is not
supposed to do that but rather make things EASIER for me.

Otherwise, if things get too hairy, I can always go back to the simple system
type your mail when you log in and delete it thing.  It seems that an
intelligent person can actually work in this mode.  I know a lot of hackers,
including some quite famous ones, who do exactly this.  If that surprises you,
I am surprised that an intelligent person can use TOPS-10 or such utterly
primitive text editors as SOS or TECO (not referring to ITS TECO, but even
that is primitive compared to the editors written in it) or (ick!)LINED.

-------

End forwarded message
-------

Date: 3 Aug 1977 0217-PDT
Sender: GEOFF at SRI-KA
Subject: Re:  Integrity of mail headers and presidents
From: GEOFF at SRI-KA
To: Header-People at MC    
Message-ID: <[SRI-KA] 3-Aug-77 02:17:16.GEOFF>
In-Reply-To: Your message of August 2, 1977  

I think at one time ARPA funded some effort to try and guarantee
the integrity of mail headers; but I think that was flushed for
some reason.  Does anyone in the group know about that effort,
and what happened to it?  If I don't hear anything, and get signs
of interest, I will poke around elsewhere and see what I come up
with -- It certainly would be interesting to see how they did it
or thought they might have been able to pull it off.
------- 

Date:  3 AUG 1977 0616-PDT
To: Header-People at MIT-MC
From: Hathaway at AMES-67
Subject: "Certified Mail"

Yes, I know about the "certified mail" attempt.  Basically what
it was was the definition of a "protected" socket to be used to
send mail from.  The receiver FTP could then check to see if the 
mail was coming from the protected socket and would know that
at least to the best of the sending operating system's ability,
the mail was from whom it was purported to be.  It was not so
much concerned with headers as contents, though -- to let you
know that mail signed "RKPAWH" on my system (my TSS userid) was
in fact from me (again only within the level of confidence you
have in my operating system's ability to protect userids and
local sockets).  Don't remember the RFC which started the whole
mess, but in fact we do have the damn thing implemented!
 
Wayne H.
------

Date:  3 AUG 1977 0902-PDT
From: POSTEL at USC-ISIB
Subject: "Certified Mail"
To:   Header-People at MIT-MC
cc:   postel

Try RFC 644 (NIC 30874) "On the Problem of Signature Authentication
for Network Mail" by Bob Thomas 22-July-77. The people who worked on the
Tenex version were Bob Thomas and Julie Sussman.
--jon.
-------

