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 srvr: 540 RFC1776 user: RCVMSG RFC724 srvr: 200 Okay... 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 server: 200 RFC724 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 server: 200 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] - 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] - 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: 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 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 ; Suggest 6 chars max for names. ; a null name is the same as UNDEF! To which the server must reply either: 200 ... ; accepted Or: 540 ... ; 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 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 stuff and provides an optional check for 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 types to work; the future structured protocol could easily be an 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 <> [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 -- 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 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 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 . 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 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]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]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 "" 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--].addresseeHOST 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]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]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]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]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]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]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]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]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]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 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]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 . 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]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]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 ). 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: