Date: 30 Sep 1977 1558-EDT Sender: VITTAL at BBN-TENEXA Subject: The header standard (what else?) From: VITTAL at BBN-TENEXA To: header-people at MC Message-ID: <[BBN-TENEXA]30-Sep-77 15:58:57.VITTAL> This set of comments is an attempt to clarify our position and enumerate the changes made to 724 over the past long while, since the last publised draft. A copy of the new draft is available as [ISI]STANDARD.DRAFT. First, thanks go to KLH. We're using his syntax, except that the concept of the lexical analyzer is retained. Dates: We are including in the syntax all of the forms of dates which seem reasonable. ANSI, military and good old American(?) have been used as the base. Day of week is also allowed. Addresses: There are two driving forces here. One is generality, the other is the ability of the sender to express his intensions in such a way that the receiver can figure them out. Some of those intensions are entities such as group names. We realize that a generalized syntax for the two general kinds of addresses (i.e. a person with multiple mailboxes, and groups) could be syntactically identical and conceptually equivalent, but you wouldn't be able to figure out the distinction on the receiving end. We are also including the notion of address types. There are four: the default standard address (no explicit type associated with it), Postal addresses, an indirect pointer to a file to be included at this place in the address list, and a catch-all type with no defined semantics. Multi-net: We have to be able to distinguish what gets put in messages, and what gets passed to the mail sending program (e.g. FTP). Right now, an address is something like a phrase followed by a host indicator. The destination address is the phrase. If there is some special mechanism on the receiving end for deciphering that phrase and doing something special like forward it on to another network, that's fine. I don't think we should specify the form that that addresses which actually gets passes to the sending program takes -- among other things, it is not in the domain of this committee to recommend that anything happen to anything other than mail creation programs, and reading programs insofar as they need to understand the contents of messages. Fld-names: Several things. Spaces in field names are ok. However, we explicitly disallow folding and comments in field names. We are (only) RECOMMENDING an ordering of field names. This is Date, From, Subject, Sender, To, Cc, ...., Message-id. Multiple occurrences of fields are explicitly discouraged. Msg-Id: Message id's are NOT explicitly required. Don't forget that it is probably the case that NOBODY will want to type one in by hand, and programs will have hooks for moving them around or searching for a particular message, etc. Privacy: The privacy issue does not belong in the RFC and is not included. Other: There was once a problem with being followed by either or . This is the case while the message is being transmitted over a TELNET NVT connection -- that is, it is a requirement of the network. Actually, this requirement will tend to be transparent to the mail software. -------  Date: 30 SEP 1977 2116-EDT From: RMS at MIT-AI (Richard M. Stallman) Subject: [ISI]STANDARD.DRAFT To: Dcrocker at USC-ISI, VITTAL at BBN-TENEXA CC: header-people at MIT-MC An attempt to retrieve this file gets the error message "451 You have not supplied a name and password". I had already supplied the file's name, so I am not really sure what this means. I am afraid I am used to computers which are designed to facilitate work.  Date: 30 Sep 1977 2039-PDT Sender: GEOFF at SRI-KA Subject: Re: [ISI]STANDARD.DRAFT From: Geoff at SRI-KA (Geoffrey S. Goodfellow) To: RMS at MIT-AI Cc: Dcrocker at USC-ISI, VITTAL at BBN-TENEXA, Cc: header-people at MIT-MC Message-ID: <[SRI-KA]30-Sep-77 20:39:28.GEOFF> In-Reply-To: Your message of September 30, 1977 MOST TENEX SITES SUPPORT THE ANONYMOUS LOGIN FEATURE IN FTP, SO BEFORE YOU SUPPLY THE FILE NAME GIVE IT USERNAME ANONYMOUS PASSWORD FOO(OR ANYTHING YOU PLEASE); THEN YOU CAN FTP AWAY. I DO NOT KNOW WHY IT DOESN'T DO AN AUTOMATIC ANONYMOUS LOGIN IF YOU DON'T LOGIN BEFORE GETTING A FILE. -------  Date: 2 Oct 1977 1409-PDT From: TVR at SU-AI (Tovar) Subject: Encryption and Msg-IDs To: RMF at MIT-MC, Header-people at MIT-MC BH made an interesting observation about both encryption and Msg-ID's, that is, the decision is currently being considered on the wrong end of the transmission. Therefore, I would like to suggest that both of these be options of FTP protocol. The two options would be Encryption: 'SECURE ' (or something like that) would be used in place of 'MAIL ', a system desiring to use Msg-ID would sent this as an informational message (which the current protocol indicates can be ignored) as a preface to sending the confirmation to send. [RAND used a similar mechanism indicate that its mail system was monitored]. Having seen this, the mail program could then include the message-ID as part of the header. To RMF: An interesting note on message-IDs as means of flushing duplicate messages. I recieved two copies of your recent message, Subject: cryption, which well illustrates why it should not be used for detecting duplication. The first copy which i recieved was garbled in such a way as for me to not understand what you were talking about. The second copy was intelligible. If duplications were eliminated by text comparison, I would have gotten both messages. But if message-ID's were used, I would only have recieved the garbled one! Obviously, you don't understand the point of Diffie, et al. encryption. It is a public key cryptosystem, which means the encrpytion key is public knowledge (on file somewhere) and you don't have to know the person you are trying to send a secure message to. -------  Date: 2 Oct 1977 1436-PDT From: TVR at SU-AI (Tovar) To: Header-People at MIT-MC Awhile ago, I sent out a suggestion for a small change to 724 to recommand that redundant information (i.e. FROM=SENDER, etc.) not be included in the header. What do people think about that? As far as the privacy issue is concerned, how about adding something to the header which is the postal equivalent of PERSONAL. Obviously, this solves no technical problems whatsoever. Nor will it stop any prying types. However, it would serve to discourage people who as a matter of their jobs and/or technical curiousity from looking at messages which are private in nature. The corporate vs. private issue is a sticky one. While it may be predominately corporate on this network, standards set here are likely to propagate elsewhere and I feel that some thought should be given privacy issues. Otherwise, we could either end up with many different protocols or else one rather lacking in privacy in the public sector. I agree with the many who have said the only really secure mailbox is one in personal computer kept at home. Beyond that, I go by the old adage: 'Locks are to keep honest people honest.' --- Tovar -------  Date: 2 Oct 1977 1849-EDT From: Philip Karlton at CMU-10A Subject: Standard.Draft To: Header-People at MIT-MC Sender: PHILIP.KARLTON at CMU-10A Message-ID: [CMU-10A] 2 Oct 1977 18:49:51 Philip Karlton Some comments and nitpicks: Page 7, III.B.1.e has the example "Muhammed(I am the greatest)Ali at(the)WBA". It is not made clear but I think that the intention is that the FTP server should get the mailbox name "Muhammed Ali" with exactly 1 space. If this is the case, it should be explicitly stated. Page 13, III.E. Why not recommend a time format like a date format is recommended. My choice would be the ANSI standard 24-hour format. Page 17, IV.A.2.b. Is the standard asking for a PERSON or a USER? If a shared login name is used, must an individual's name be included? If the local mail deliverer can only understand a mailbox as an address, then must the Sender: field contain the person's name in a comment or a mach-id? Page 19, IV.B.2. Why are <>s required in In-Reply-To: fields? Pages 24 and 25, V.D.2 and V.D.3. <>s are given in the examples in the Message-ID: fields. They are not mentioned in the syntax part. Are they needed? Is there a worry about leading or trailing white space getting in the way of message-id matches? These are the things that I noticed on my first reading of the draft. It could be that I just missed the answers to my questions. I do have one further question that just occured to me. Does the extensive use of the form "Alfred E. Newman Is that what we can all expect to see more of in times to come?? Mail from RAND-UNIX rcvd at 3-Oct-77 1309-PDT Date: 3 Oct 1977 at 1259-PDT From: Greep at Rand-Unix To: Feinler at Sri-Kl, GEOFF at Sri-Ka Subject: Re: Wharton New hosttable available (v.243) In-Reply-To: Messages of 3 Oct 1977 1114-PDT by Feinler at SRI-KL and 3 Oct 1977 1159-PDT by Geoff at SRI-KA (Geoffrey S. Goodfellow) <[SRI-KA] 3-Oct-77 11:59:45.GEOFF> Message-ID: <[Rand-Unix] 3-Oct-77 12:59:27.Greep> .... It would have looked even nicer if Jake would have used a message-id to on her reply, ... shucks. -------  Date: 3 Oct 1977 at 1403-PDT Subject: Re: Carrying things just a little to far (or In-reply-to grossage) From: Greep at Rand-Unix To: GEOFF at Sri-Ka cc: Header-People at Mc Message-ID: <[Rand-Unix] 3-Oct-77 14:03:58.Greep> In-Reply-To: Your Message of 3 Oct 1977 1324-PDT In-Reply-To: <[SRI-KA] 3-Oct-77 13:24:45.GEOFF> I thought you knew about the multiple reply in MS. If you want to have fun some time, do a 'reply all' and watch the fireworks. If you have more than two messages, it puts the commas in also.  Date: 4 Oct 1977 at 1038-PDT Subject: This last round with the Standard From: Dcrocker at Rand-Unix To: Header-People at Mit-Mc Message-ID: <[Rand-Unix] 4-Oct-77 10:38:39.Dcrocker> This is to clarify what it is we would like Header-People to do with this last draft of the standard. (Burning it and subjecting it to verbal abuse are, of course, available alternatives, but not ones we recommend.) We are primarily looking for a final technical proofing. Syntactic (and semantic) ambiguities and typos are our particular concerns. We have been revising the thing continually (up to the last 15 minutes we worked on it) and so are having a difficult time seeing the text clearly. The sorts of responses made by Killian and Karlton are just right. Any and all othera sent by Friday (7 Oct) will be greatly appreciated. We plan to pass the document off to Walker on Monday. Also, hassles and noise aside, we have appreciated all the time, energy and thought you guys (hmmm, yes, I guess no women were involved) have put into this. We could have wished for more agreement on the philosophy of the approach, but then we wouldn't have had to justify it so well (to ourselves, at least). Dave (for Ken, John, and Austin, also)  Date: 4 Oct 1977 1650-EDT From: Rick Gumpertz at CMU-10A Subject: Re: This last round with the Standard To: Dcrocker at Rand-Unix CC: Header-People@MIT-MC Sender: RICK.GUMPERTZ at CMU-10A Message-ID: [CMU-10A] 4 Oct 1977 16:50:23 Rick Gumpertz In-Reply-To: <[Rand-Unix] 4-Oct-77 10:38:39.Dcrocker> Isn't one week a bit short notice -- I just got back from a long weekend and have only 3 days to gen all comments??? Rick -------  Date: 4 Oct 1977 1801-EDT From: Rick Gumpertz at CMU-10A Subject: latest RFC 724 To: Header-People@MIT-MC Sender: RICK.GUMPERTZ at CMU-10A Message-ID: [CMU-10A] 4 Oct 1977 18:01:32 Rick Gumpertz Some quick comments on latest revision: 1) Why still allow slash dates and 12 hour times?? Why allow optional dashes in string dates?? Both of these just make things harder for smart mail readers (or implementers thereof). If you must include it, at least justify it in the standard! 2) As was pointed out to me a long way back in the header people discussion, "M" is an official (see any dictionary) abbreviation for the thing that AM is ANTE and PM is POST, namely MERIDIES or NOON. Make the losers who want to use 12 hour time spell out Midnight or Noon -- the two abbreviations are not that much shorter. Point out also that 12:00 AM is equivalent to 00:00 and 12:00 PM is equivalent to 24:00, for anyone who doesn't realize it. The former is 24 hours before the latter, for a given date. By the way, "A" and "P" are downright silly. 3) I initially misread linear-white-space and linear-white-space-char as being the same thing. Maybe you should rename the latter to LWS-char or such, to make it more obvious. Long names tend to be glossed over rather than read carefully. 4) Why don't extension-field and user-defined-field at least appear in the APPENDIX, perhaps as a reference like ";See section ..."? 5) What is the "delimiters" non-terminal used for? If for lexical analysis, it should surely include "+", "-", etc. 6) The point marks ("o") in IV.A.1.c should be "outdented" from the first 2 paragraphs, as it is for the last two. 7) Please add more info as to what I do with a host-indicator to understand it in my current context, i.e. reform it into "at" where is a locally addressable host or net and is a string it will understand. More to come ... Rick -------  Date: 4 Oct 1977 1813-EDT From: Rick Gumpertz at CMU-10A Subject: RFC 724 To: Header-People@MIT-MC Sender: RICK.GUMPERTZ at CMU-10A Message-ID: [CMU-10A] 4 Oct 1977 18:13:09 Rick Gumpertz Another quickie: Can I say "<<>>" or "foo at bar >" as an address?? The recursion on address would seem to indicate so. What if anything, do the above mean?? Rick -------  Date: 4 OCT 1977 2058-EDT From: KLH at MIT-AI (Ken Harrenstien) To: Header-People at MIT-MC I will first list the minor things I came across. * Page 4, III.A.4 shows "2D" and "3A" as examples, but in the actual spec one would have to say 2DIGIT and 3ALPHA. Personally I much prefer the brevity of D and A (or L for Letter, I confuse ALPHA with Alphanumeric), but these things are mostly a matter of personal style. I will just opine that the date-format rules look much better with D. * Page 8, III.B.2 definition of field and field-body is mildly mixed up about CRLF. explicitly includes a CRLF, but says that is optional, hence one may have a field-name without a crlf? Suggest that a CRLF be put to follow the "[field-body]" in def of , and the "[" in be moved to precede the "CRLF". * Page 10, III.B.c Quoted-string paragraph is missing a period. One might however, instead of adding just ".", use "; i.e. the CRLF is kept, and the first following white-space-char is thrown away." Just to make it really clear. * Is there some reason why 24-hour time cannot have separating colons? It seems to me that 12-hour, which does, can be distinguished from 24-hour by the prsence/absence of AM/PM designators. Colons make the time much easier to read if one is using seconds; who wants "231115" when you can have "23:11:15"? I agree with Phil that a recommendation would be a good idea, and that 24-hour (with colons) is most appropriate. I would also suggest that whenever possible, the "North-Amer-zone" be used in preference to military or numerical offset; the latter two are useful for places in unusual locations, but otherwise confusing. If people are going to have to have their mail readers convert times to some format which they prefer, it should be the military which has to do the conversion, because they are most apt to be using hairy readers and have the necessary funds and clout to make their readers do so. For this reason I don't think it would be any hardship to forget about military zones, and rely on nmerical offset (much more general) to handle oddball zones. And meanwhile the research people with simple readers will see something they are familiar with. * Page 2, II at bottom. capabilties => capabilities. * Page 21, V.A.1 "BBN- TENEXA" should be "BBN-TENEXA". * Page 22, V.B There is no comma ending the "Cooks:" group, as is required. Similarly for the "Important folk:" group on page 25, V.C.3 -- just an oversight, but examples are important. * Page 19, IV.B.1 Message ID semantics still do not make it clear what sort of processing is allowed on an ID. For example the syntax allows comments; are comments to be ignored? Or treated as part of the string? etc... The comments next to the BNF imply that one treats the stuff between brackets as a literal string, but this needs to be elaborated on in IV.B.1 for the reasons I have previously given in my comments on 724. * Paage 20, IV.D - "12:01 is equivalent with "00:01" - does this imply that 12:02 = 00:02 and in general 12:dd = 00:dd? Should state. Also, the explanation of military zones can be better phrased; it should be made clearer that it is a sequence, as in "A: -1, B: -2,... M: -12, N: +1,... Y:+12". The comments in the BNF should at the least say "etc.", assuming that we are keeping mlitary zones at all - I think the original suggestion was made more in jest than earnest. * Page 17, IV.A.2.b I echo Phil's comments; this section is CONFUSING. Particularly the last sentence: "The phrase (user) is a system entity, not a generalized person reference". Now that beats me. I remember that I managed to figure it out in 724, but I've forgotten again and it's a real pain having to figure it out each time. At the very very least, either say "phrase '(user)'..." or "phrase (i.e., user)", but don't stop there. These were the easiest things. I or others will have more to say later about more significant details.  Date: 4 Oct 1977 2036-PDT From: MRC at SU-AI (Mark Crispin) Subject: Last round with 724 To: Header-People at MIT-MC So that's what's wrong with Header-People and RFC 724!!! It lacks a woman's touch!!! Well, that will have to be amended. -------  Date: 4 Oct 1977 2038-PDT From: MRC at SU-AI (Mark Crispin) To: Gumpertz at CMU-10A, Header-People at MIT-MC Rick, you're wrong. 12:00 PM is 12 Noon. -------  Date: 5 OCT 1977 0001-EDT From: KLH at MIT-MC (Ken Harrenstien) Subject: Sexism or lack of it To: mrc at SU-AI, dcrocker at RAND-UNIX CC: HEADER-PEOPLE at MIT-MC That's interesting, apparently most arpanet mail addresses don't lend themselves to discrimination. On the other hand, this can lead to certain gaffes, which the three or so women in Header-People may or may not wish to point out.  Date: 5 OCT 1977 0029-EDT From: KLH at MIT-MC (Ken Harrenstien) To: Pogran at MIT-MULTICS, Dcrocker at USC-ISI, Vittal at BBN-TENEX To: Henderson at BBN-TENEX CC: HEADER-PEOPLE at MIT-MC " We could have wished for more agreement on the philosophy of the approach, but then we wouldn't have had to justify it so well (to ourselves, at least)." It seems to me that one might stave off a goodly amount of ill will by justifying it to others as well. I am willing to listen to arguments, re-think positions, and spend the necessary time to expostulate my opinions and their motivations; I feel hurt when this is not done in return. Is it that difficult to communicate?  Date: 5 Oct 1977 0029-EDT From: Philip Karlton at CMU-10A Subject: Recent suggestions and questions To: Header-People at MIT-MC Sender: PHILIP.KARLTON at CMU-10A Message-ID: [CMU-10A] 5 Oct 1977 00:29:25 Philip Karlton This is a plea to the authors of the upcoming RFC to send to Header-People their answers and comments. If it is possible, I would like to see the responses listed explicitly on a point by point basis. For many a simple phrase will probably suffice. PK -------  Date: 5 Oct 1977 0942-EDT From: Rick Gumpertz at CMU-10A Subject: 12:00 PM To: MRC at SU-AI (Mark Crispin) CC: Header-People at MIT-MC Sender: RICK.GUMPERTZ at CMU-10A Message-ID: [CMU-10A] 5 Oct 1977 09:42:37 Rick Gumpertz In-Reply-To: Your message of October 4, 1977 No, I am not wrong. 12:00 PM is, by definition, POST MERIDIEM or after noon. It IS definitely 24:00. Just because your AM/PM digital clock can't handle it isn't justification to distort that fact. 12:00 PM immediately precedes 12:01 AM the next day, as silly as that may seem for computer people used to reasonable CARRY schemes in their counters. Rick -------  Date: 5 Oct 1977 1024-EDT From: Rick Gumpertz at CMU-10A Subject: 12:00 PM vs. AM To: Header-People at MIT-MC Sender: RICK.GUMPERTZ at CMU-10A Message-ID: [CMU-10A] 5 Oct 1977 10:24:04 Rick Gumpertz OK, as far as I am concerned, 12:00 xM is ill defined. From talking to various people I got their impressions of "common usage": 12:00 AM: 00:00, 24:00, undefined 12:00 PM: 24:00, 12:00, undefined Therefore I now suggest that the standard specifically prohibit times of the form 12:00 xM. While trying to research the issue, I could find no information in any of the traditional references. Does anyone know of an "authoritative" source to settle this issue, if it can be settled?? My curiosity is now aroused. Rick P.S. Wouldn't it be much simpler to eliminate 12 hour times? -------  Date: 5 Oct 1977 1028-EDT From: Rick Gumpertz at CMU-10A Subject: rfc 724 quoted addresses To: Header-People@MIT-MC Sender: RICK.GUMPERTZ at CMU-10A Message-ID: [CMU-10A] 5 Oct 1977 10:28:48 Rick Gumpertz If I get mail from "quoted/string" at RFC-724, and I try to reply to it, do I tell FTP to send to quoted/string or to "quoted/string"? I.e. do I drop the quotes since FTP delimits names by and will allow anything else up to the . Rick -------  Date: 5 Oct 1977 1243-EDT From: Brian Reid at CMU-10A Subject: Re: 12:00 PM vs. AM To: RICK.GUMPERTZ at CMU-10A CC: Header-People at MIT-MC Sender: BRIAN.REID at CMU-10A Message-ID: [CMU-10A] 5 Oct 1977 12:43:49 Brian Reid In-Reply-To: [CMU-10A] 5 Oct 1977 10:24:04 Rick Gumpertz From my experiences in the Airline business, I believe that (believe it or not) the U.S. Coast Guard is the keeper of thhe standard for everything having to do with times, time zones, and naming conventions. I'll bet that NBS has a publication on it, though. If Justin Walker is in Header-People, he should be able to put his finger on something. -------  Date: 5 Oct 1977 1004-PDT From: MRC at SU-AI (Mark Crispin) To: Gumpertz at CMU-10A CC: Header-People at MIT-MC 05-Oct-77 0644 FTP: Rick Gumpertz at CMU-10A 12:00 PM Sorry Rick. 12AM is midnight; 12PM is noon. Not only is that what has been taught in all elementary schools, but also all the computers I tested it out on all agree on that. Of course, you may choose to redefine 12AM and 12PM for our own good like most everything else has been. Being a human being and not an abstraction, I prefer the system which other human beings are using. -------  Date: 5 OCT 1977 1047-PDT To: Header-People at MIT-MC From: Hathaway at AMES-67 Subject: The absurd discussion on AM and PM Header-People would get along a lot better without the continuing belligerence of people like Marc Crispin -- particularly in light of his rather overwhelming ignorance. 12:00 p.m. on January 10 is the exact same time as 12:00 a.m. on January 11, and BOTH are midnight. The correct abbreviation for noon is 12:00 m., the "m." standing for "merides." Because of the obvious confusion this can cause, many style manuals recommend abbreviations "n." for noon and "mid." for midnight. For those who are interested, the first time this issue was raised was on November 1, 1976 -- see the Header-People files! Wayne Hathaway. ------  Date: 5 Oct 1977 1100-PDT From: Feinler at SRI-KL Subject: Midnight sun To: header-people at MIT-MC cc: feinler Isn't it the Coast and Geodetic Survey that does this sort of standard (don't know if that is or is not the Coast Guard). My understanding of common usage is that noon and midnight are never assigned 'AM' or 'PM' to them, but haven't found formal backing for that myself either. Jake -------  Date: 5 Oct 1977 1106-PDT From: Feinler at SRI-KL Subject: Postscript To: header-people at MIT-MC cc: feinler Obviously MRC and I went to different schools together! P.S. I have one of our Reference Librarians looking into it.....more later. Jake -------  Date: 5 OCT 1977 1323-PDT Sender: DCROCKER at USC-ISI Subject: Re: 12:00 PM vs. AM From: DCROCKER at USC-ISI To: RICK.GUMPERTZ at CMU-10A Cc: Header-People at MIT-MC Message-ID: <[USC-ISI] 5-OCT-77 13:23:14.DCROCKER> In-Reply-To: [CMU-10A] 5 Oct 1977 10:24:04 Rick Gumpertz ANSI standard does not deal with it. I had the Rand Reference librarian do some searching and she finally gave up. Apparently, there is no "official" standard. D/ -------  Date: 5 Oct 1977 1814-PDT From: MRC at SU-AI (Mark Crispin) Subject: AM/PM controversy resolved To: Header-People at MIT-MC From the Encyclopaedia Britannica, 1975 edition, volume 18, page 414: "In the 12-hour system there are two sets of 12 hours; those from midnight to noon are designated AM (ante meridiem, "before noon"), and those from noon to midnight are designated PM (post meridiem, "after noon"). There use of AM and PM to designate either noon or midnight can cause ambiguity..." Having gotten that wishy-washy definition from the Britannica (*Sigh*), I then proceeded to check common usage. Every computer program I examined on several systems (including monitors, login programs, date and time programs,...) used 12AM to refer to midnight, and 12PM to refer to noon. Some people (a minority) said they thought the exact opposite, but that they never used AM/PM, so it didn't matter. However, EVERY SECRETARY I talked to agreed that 12AM is midnight, and 12PM is noon. This is using definite beginning for a time period and indefinite ending (ie, 11:59:59 is not the end since 11:59:59.9 is still in the "previous time"...we all remember limits, don't we?). I would think that in matters such as this when the authorities fail us for a definition of this that a secretary is an order of magnitude more knowledgeable about common usage than a computer programmer. Of course, that has nothing to do about whether AM or PM should be used. If you guys had argued about that, that would be something totally different. Saying "there is no official standard for AM and PM" is different from saying "you are ignorant for not agreeing with me". On the basis of this confusion, AND to make the military types happy, the 24-hour clock should be used. It is certainly less objectionable to get mail with a 24 hour format than with somebody's random standard of the 12 hour clock (ESPECIALLY one not in common usage). P.S. Wayne, if you are so knowledgeable that you can go around calling me names how come you can't spell my name right? -------  Date: 5 Oct 1977 1624-EDT From: Philip Karlton at CMU-10A Subject: Re: The absurd discussion on AM and PM To: Header-People at MIT-MC Sender: PHILIP.KARLTON at CMU-10A Message-ID: [CMU-10A] 5 Oct 1977 16:24:40 Philip Karlton In-Reply-To: Your message of October 5, 1977 I recommend that 12 hour time be flushed from the standard. I admit that I feel this way since I find it to be more convenient for personal use. Does anyone out there really want or need 12 hour time? If no one will say yes, then we can stop this discussion. PK -------  Date: 5 Oct 1977 2200-EDT From: Brian Reid at CMU-10A Subject: 12-hour time To: PHILIP.KARLTON at CMU-10A CC: Header-People at MIT-MC Sender: BRIAN.REID at CMU-10A Message-ID: [CMU-10A] 5 Oct 1977 22:00:04 Brian Reid In-Reply-To: [CMU-10A] 5 Oct 1977 16:24:40 Philip Karlton I think in 12-hour time, and want to see it printed. -------  Date: 5 Oct 1977 2238-EDT From: Rick Gumpertz at CMU-10A Subject: Re: The absurd discussion on AM and PM To: PHILIP.KARLTON at CMU-10A CC: Header-People at MIT-MC Sender: RICK.GUMPERTZ at CMU-10A Message-ID: [CMU-10A] 5 Oct 1977 22:38:18 Rick Gumpertz In-Reply-To: [CMU-10A] 5 Oct 1977 16:24:40 Philip Karlton I agree with Phil totally -- this is why I brought up the issue yesterday and last year. Nevertheless, the mysterious ways in which CAHCOM seems to work have left me believing that 12 hour time will stay in for some undisclosed reason. Therefore I decided the issue should get out in the open, just so people will agree what is meant when some losing program does generate 12:00 xM. If 12 hour time must stay (I see no reason for this, but then I slash my Z's, which is also contrary to common American usage) the let the standard PROHIBIT 12:00 xM and not leave the ambiguity in the M. (capitalized, according to all dictionaries I have referenced) abbreviation. When oh when will we ever get some audit trail from CAHCOM as to what went into 724? Rick -------  Date: 5 Oct 1977 2311-EDT From: Rick Gumpertz at CMU-10A Subject: 12 hour times To: Header-People@MIT-MC Sender: RICK.GUMPERTZ at CMU-10A Message-ID: [CMU-10A] 5 Oct 1977 23:11:06 Rick Gumpertz People who want 12 hour times printed can have their mail reader convert for them. After all, why should tey be subjected to the whims of the sending mailer. Another example of decision at the wrong end. Personally I find 12 hour time harder because it is harder to subtract, with an extra carry point. Rick -------  Date: 6 Oct 1977 1148-EDT From: Brian Reid at CMU-10A Subject: The AM/PM Controversy, resolved. To: Header-People at MIT-MC Sender: BRIAN.REID at CMU-10A Message-ID: [CMU-10A] 6 Oct 1977 11:48:18 Brian Reid Begin forwarded message - - - - - - - - - Date: 6 Oct 1977 (Thursday) 0235-Est From: DUNLAVEY at NBS-10 Subject: Time To: BRIAN REID(C410BR10) at CMU-10A Brian, Dr. Hall of the Time Service Division, U.S. Naval Observatory, Wash. D.C. says that there are no standards nationwide to distinguish the meaning of 12 a.m. and 12 p.m. They are and always have been ambiguous. It was for this reason, he says, that train schedules never use either, but 11:59 or 12:01 instead (I never noticed this myself). "Noon", of course, is unambiguous for a given day; but "midnight" must be given as between two specific dates. The 24-hour clock removes most of these ambiguities, but even then the use of 2400 hours is discouraged, and 0000 hours is always used to denote the beginning of the specificied day. For further of information you may contact Dr. Hall at: (202) 254-4486 Any time, Dick End forwarded message -------  Date: 6 Oct 1977 1156-EDT From: Brian Reid at CMU-10A Subject: and then some To: Header-People at MIT-MC Sender: BRIAN.REID at CMU-10A Message-ID: [CMU-10A] 6 Oct 1977 11:56:57 Brian Reid Begin forwarded message - - - - - - - - - Date: 6 Oct 1977 1155-EDT Sender: DDEUTSCH at BBN-TENEXA Subject: Re: A.M. and P.M. time designation standard From: DDEUTSCH at BBN-TENEXA To: BRIAN.REID at CMU-10A Cc: Mooers, DDeutsch Message-ID: <[BBN-TENEXA] 6-Oct-77 11:55:00.DDEUTSCH> In-Reply-To: Your message of October 5, 1977 According to "A Manual of Style" , 12th edition completely revised (The University of Chicago Press) the time of day may be referred to as follows. (You may find this on page 324, section 14.30.) A.M. ante meridiem (before noon) M. meridies (noon) P.M. post meridiem (after noon) By this reckoning, midnight is 12:00 PM. This is also pointed out on page 201, section 8.20, where it is explicitly stated that 12:00 M. is noon and that 12:00 P.M. is midnight. I hope this clears up the controversy. Debbie P.S. I am indebted to Charlotte Mooers for her help in this matter. ------- End forwarded message -------  Date: 6 Oct 1977 1914-PDT From: MRC at SU-AI (Mark Crispin) Subject: More garbage on AM/PM To: Header-People at MIT-MC Has anybody thought that time is an analog quantity, not digital? That means that we round 12:00:00.1 to 12, even though it is actually AFTER noon. Even if we could insure accuracy of our computer's clocks (look at a compilation of output from time servers across the network some time!) it is still wrong to talk about exactly noon and exactly midnight; since (at least on most machines) if a process reads a time of noon it is actually a couple of microseconds after noon, or accurate to the resolution of the system clock. Many places still use line frequency clocks, which could be as much as 1/50 of a second or more off! That just makes the AM/PM issue redundant, since we are talking about the time as being t plus some small quantity. That makes 12AM "midnight" (or rather, midnight+ small t) and 12PM "noon" (noon+ small t). Why not just say the hell with it and use 24hour times (0000-2359)? I like the 12 hour clock for personal use but it's not worth the effort. Also, it makes the header shorter by two characters (every little bit gained and all that...) and less for hairy mail reading programs to have to parse (something for the other side too). -------  Date: 7 OCT 1977 0710-EDT From: RMS at MIT-AI (Richard M. Stallman) To: header-people at MIT-MC One thing that isn't clear to me from the proposed standard is whether "<" - ">" constructs are supposed to be able to be nested, and exactly what it means when they are? The SYNTAX clearly says that they are supposed to balance and that nesting is well-formed. Also, while the SYNTAX says that spaces are permitted in field names, nothing is said about their semantics. Is this an example of a FROM field? "FROM : RMS@MIT-AI" I would suggest that that NOT be permitted, for ease of parsing.  Date: 7 OCT 1977 1512-EDT From: RMS at MIT-AI (Richard M. Stallman) To: header-people at MIT-MC I don't see that the proposed standard specified where whitespace is necessary and where it is not. Now, I can make "the obvious assumption" which I think is intended, which is that "FOO" and "BAR" need a space between them, but "FOO" and "," do not, but nothing seems to say that and there may be cases which are not so obvious.  Date: 7 OCT 1977 1401-PDT To: Header-People at MIT-MC From: Hathaway at AMES-67 Subject: A.M., P.M., and belligerency I was quite pleased to see the note from Debbie the other day with the quote from "A Manual of Style," as that is the sort of thing that obviously should take place in such deliberations. I was a bit distressed with her statement that "... it is explicitly stated that 12:00 m. is noon and 12:00 p.m. is midnight." Please note that this does NOT state that 12:00 a.m. is not also midnight, and in fact it is; all that the style manual says is that the preferred way of writing midnight is 12:00 p.m. This of course stems from the fact that midnight is considered to be at the end of a day rather than at the beginning ("The bomb went off last midnight" rather than "The bomb went off at midnight today."). As additional support for my rather pointless position that 12:00 a.m. and 12:00 p.m. are both midnight, I submit the following quote from "The McGraw-Hill Encyclopedia of Science and Technology," 1977, pages 659-660: In civil life the designations a.m. and p.m. are often used, usually with punctuation between hours and minutes: thus 1009 may be written as 10:09 a.m. and 1509 as 3:09 p.m. In this system, noon is correctly designated as 12:00 m. Sometimes July 2, 2400 is called July 2, 12:00 p.m. The designation July 3, 12:00 a.m. is not used, although it is logically the same as July 2, 12:00 p.m. The designations for noon and midnight are, however, often confused, and it is better to write 12:00 noon and July 2-3, 12:00 midnight in order to avoid ambiguity. In some occupations where time is of special importance, there is a rule against using 12:00 at all, 11:59 or 12:01 being substituted. The time 1 min after midnight is 12:01 a.m. and 1 min after noon is 12:01 p.m. Can we please settle on something nice like the style manual's version and forget this mess? And now one personal note to Mark: I apologize for misspelling your name; I think the frequent use of "MRC" snuck into my subconscious. But I must take exception to your claim that I called you "ignorant for not agreeing with me," as I most assuredly never did any such thing. If you had spelled "secretary" as "secketerry" then I think you would agree with my use of the term ignorant, no? Well, as far as I am concerned you are misusing the English language just as much with the "12:00 p.m. is noon" thing (and for that matter, just by writing "a.m." as "AM" all the time), and thus qualify for my description. Admittedly that's a matter of personal opinion; I think your belligerency is more a matter of public record, as the following quotes show quite well: "Of course, you may choose to redefine 12AM and 12PM for our own good like most everything else has been." "I think you have adequately demonstrated ... that you are totally intolerant of any opinions other than your own." "I was on the verge of sending a very nasty reply to one of your earlier messages but thought better of it since all you would do is send a computer equivalent of giving the finger." "Thank you, CMU hackers, for providing such outstanding examples of maturity ..." "Maybe if CMU concentrated on making their mailer WORK they wouldn't be so fired up on making their headers so hairy." "I hope the people out there are listening, and aren't going to continue to simply ignore what may well be at least 50% of the ARPAnet community." "Yes, I know I am asking the impossible; since you are so willing to assume that anything I say is unreasonable you immediately will do just the opposite just to disagree." Enough said? Electronic mail systems are fun! Wayne H. ------  Date: 7 OCT 1977 1826-EDT From: KLH at MIT-AI (Ken Harrenstien) To: Header-People at MIT-MC [1] RMS has sent a simpler version of XSYN to the committee in hopes that we can preserve the essential idea of balanced-bracket structure for typed addresses. i have urged him to make it available to the rest of Header-People; it is the main point of dispute, I think, for ITS people. [2] Perhaps we should contact Steve Walker and arrange for an extension to the deadline by explaining that the current draft has some cloudy points which can be cleared up in a couple of weeks. [3] For example the AM/PM issue. Having just learned more about this topic than I ever dreamed was possible, I would strongly support the removal of 12-hour time from the standard. It will be much easier for everyone, especially those people who write converters-to-am/pm for those who want them. My only remaining question is, are 0000 and 2400 really ambiguous? The former is (or at leat implies strongly) the begining of the day, and the latter the end thereof; thus 2400 April 12 is 24 hours after 0000 April 12, and while it is the same as 0000 April 13 there is no confusion as to what point of the year you are talking abut; ie how many hours it has been from the year's beginning, for example, and it is absolute conversions of ths sort that I expect converter routines will use.  Date: 7 OCT 1977 1431-PDT Sender: DCROCKER at USC-ISI Subject: time enough From: DCROCKER at USC-ISI To: header-people at MIT-MC Message-ID: <[USC-ISI] 7-OCT-77 14:31:23.DCROCKER> Well, we are now convinced that 12-hour time format is loaded with problems and have decided that the most reasonable solution to the particular problem of including it in the standard is not to. 24-hour time format only will be included, and ":" will be permitted within it. Dave. -------  Date: 7 Oct 1977 1948-EDT From: Rick Gumpertz at CMU-10A Subject: Re: time enough To: DCROCKER at USC-ISI CC: Header-People at MIT-MC Sender: RICK.GUMPERTZ at CMU-10A Message-ID: [CMU-10A] 7 Oct 1977 19:48:53 Rick Gumpertz In-Reply-To: <[USC-ISI] 7-OCT-77 14:31:23.DCROCKER> Isn't it amazing how much discussion was raised by one short note asking for the elimination of 12 hour time, along with some notes on the difficulty it causes?? Where else can one get so much entertainment for one short statement. Perhaps when we are discussing electronic mail with the outside world we should emphasize that it beats Hyde Park for soap-box speeches! Rick -------  Date: 7 Oct 1977 1950-EDT From: Rick Gumpertz at CMU-10A Subject: Re: time enough To: DCROCKER at USC-ISI CC: Header-People at MIT-MC Sender: RICK.GUMPERTZ at CMU-10A Message-ID: [CMU-10A] 7 Oct 1977 19:50:22 Rick Gumpertz In-Reply-To: <[USC-ISI] 7-OCT-77 14:31:23.DCROCKER> OK, what do I have to do now to get rid of slash dates too?? Rick -------  Date: 7 Oct 1977 1931-PDT From: MRC at SU-AI (Mark Crispin) Subject: all this garbage flying around To: Header-People at MIT-MC why not just forget about mail headers and restrict header people to character assasination? better yet, why not remember that this is the usa and not the people's republic of china? unless of course a drastic change has occured in the structure of the world. this all reeks of a criticism session of the gang of four. all that is being gained by arguing that "x is a cretin" is just to make x more determined not to cooperate, which gives neutral y an excuse to have his own variations, and z hers, etc. if you are going to have a standard you are going to have to consider everybody's viewpoint, no matter how unreasonable it seems to you; 'cause your favorite ideas just might be totally unreasonable to somebody else. if ya want yar personal triumphs in all things, you are only going to hurt yourself in the end. consider the political coups of the south in the years before the civil war which helped trigger it. i pick that simile since this thing has taken up the dimensions of a civil war. you simply can't go around making some people more unhappy than others. everybody has got to be equally unhappy. -------  Date: 7 Oct 1977 2347-EDT From: Rick Gumpertz at CMU-10A Subject: Re: all this garbage flying around To: Header-People@MIT-MC Sender: RICK.GUMPERTZ at CMU-10A Message-ID: [CMU-10A] 7 Oct 1977 23:47:25 Rick Gumpertz In-Reply-To: MRC's message of October 7, 1977 I think a lot of the criticism flying around has been in poor taste, mostly because it has been broadcasted rather than kept personal. Nevertheless I think certain people have been taking this awfully personally. Back up, forget the current discussion, and try to contribute in a positive manner. Rick -------  Date: 8 Oct 1977 1215-EDT From: Brian Reid at CMU-10A Subject: Airborne garbage To: Header-People at MIT-MC Sender: BRIAN.REID at CMU-10A Message-ID: [CMU-10A] 8 Oct 1977 12:15:10 Brian Reid In-Reply-To: Your message of October 7, 1977 It was my understanding that this forum was not one designed for the competition of ideas but the solution of problems. I don't have strong ego attachments to "my" ideas, and had always assumed that this group was just trying to find the answers, without regard to their source. Further, it should not be the case that we are evaluating ideas on the basis of who likes them and who doesn't. We should be evaluating ideas on the basis of their applicability to the problems at hand and the expected future problems, to be faced not by a handful of hackers and mail implementors, but by a whole new generation of network mail users. This is just no place for the assertion of personal views over rational thinking. I am glad that Dave, Austin, Ken, and John remain as a filter between this entertaining madness and the final report. As an aside, has anybody considered writing a small article for some journal or magazine about the sociological aspects of netmail committees like this one? I think that it would make a fascinating story if done right. Brian -------  Date: 9 Oct 1977 0242-PDT From: MRC at SU-AI (Mark Crispin) Subject: future network mail To: Header-People at MIT-MC if we are talking about setting the standards for the future then why are we talking about mail headers? certainly nobody is going to reasonably suggest that the future networks should use a mailing system where all the identity information occurs in an ASCII string prepended to the body of the message and where the actual mail is sent as a command to the file transfer protocol! as i understood it, a mail protocol was the "right" way, but since sooooo many places have it as a command to ftp and don't have the manpower to rewrite all the stuff and all we were going to hack headers with the understanding that a new network would want to do it the right way and not repeat the mistake. if that is so talking about future networks doesn't make sense. if that is not so i think it is awful of us to condemn future networks to having to rely upon the server process to send a universal format (and i doubt if it will ever be universal no matter what is done; somebody will do something that some other mail reader will blow its mind on someplace and nasty accusations will fly back and forth about so-and-so violating mail protocol and so-and-so will say well, such-and-such doesn't have any problem and we like our way of doing things,...). haven't we had enough of this with telnet and the ftp protocol? more to come on the sociology of network links. -------  Date: 9 Oct 1977 0704-PDT From: MRC at SU-AI (Mark Crispin) Subject: sociology of computer mail (not links!) To: Header-People at MIT-MC well, actually both. i first became interested in this when i was an undergrad psychology major concentrating in organizational psych. obviously computer communications have a dramatic social impact. probably when the telephone was introduced the impact was dramatic. this is something new though; a media with no direct contact at all. hence all of the normal social inhibiting factors are removed. that is why you get all this emotional behavior (ranging from network psychoanalysis to endless debates over whether a program's behavior is a bug or a feature to love affairs! (i have heard rumors of one of the last actually becoming a marriage; probably a first in blind dating)) from seemingly unemotional "mature" people. all that is needed is the removal of other people to disapprove and the veneer of maturity gets stripped away. i sort of wonder if there is any such thing actually; as by my definition a mature people is one who does not bother with other people's behavior and does not claim to be mature him/herself. i don't think any such person exists. i see many parallels with huxley; while we don't have government distribution of soma or government scheduled sex or savage reservations or feelies or world unity yet there are other major similarities. the notable exception is the intellectual elitism; if anything this is "average elitism". viva la brave new world! -------  From: Pogran at MIT-Multics Date: 10/09/77 1523-edt Subject: Comments on selected quotations ... To: Header-People at MIT-MC Message-ID: [MIT-Multics]1.1.BBBJGpXfLGgmQQ "you simply can't go around making some people more unhappy than others. everybody has got to be equally unhappy" -- MRC "I am glad that Dave, Austin, Ken, and John remain as a filter between this entertaining madness and the final report." -- Brian Reid "if we are talking about setting the standards for the future then why are we talking about mail headers? certainly nobdody is going to reasonably suggest that the future networks should use a mailing system where all the identity information occurs in an ASCII string prepended to the body of the message and where the actual mail is sent as a command to the file transfer protocol!" -- MRC Just a few comments on what (for me) are some of the more interesting quotes from this weekend's messages: MRC is right, of course, in what he says about the standard leaving everyone equally unhappy. Given the tenor of some of the Header-People messages, you might think we (the authors) are more biased against some of the Header-People folk than we are against anyone else, but that really ain't so -- there are inputs to this standards-making process that haven't been part of the Header-People discussion. I think that MRC's remark is something to bear in mind, once the standard does become finalized. Considering that there hasn't been an AWFUL lot of agreement, even within the Header-People community, if there ISN'T some residual unhappiness on the part of most people once the standard becomes finalized, I think that would be a sign that it isn't a GOOD standard! I think the second quote at the top of this message speaks for itself. Thank you, Brian. And as for the third quote -- well, Mark, I think that, while we in the research community (especially the ARPA research community) are all agreed that structured mail protocols are the way to go in the future, and that what we're doing is an interim step, I think there are going to be a lot of networks built in the commercial (business & industrial) sector that ARE going to send mail around the way we're doing it now, and these networks are going to do that for a long time. The commercial part of the computer biz has always shown itself to lag behind what we're doing by quite a bit, and even when the forefront of the commercial sector picks up what we've been doing, the bulk of the sector with systems already "in place" isn't about to junk what they've got and pick up the latest thing. So, despite the fact that WE know the standard we're devising does not represent the "wave of the future" for us, something like it probably represents a substantial part of the future for the commercial sector. And, if our standard helps -- even in a small way -- to keep the commercial sector from floundering around as much as it might, or helps to improve what the commercial sector does, well -- that's a good thing. Who knows? Peace, Ken  Date: 9 Oct 1977 1349-PDT From: BH at SU-AI (Brian Harvey) Subject: What else? To: Pogran at MIT-MULTICS CC: header-people at MIT-MC Although I like the tone and general direction of your latest contribution, Ken, I have one minor and one major quibble. Minor quibble: You say any apparent bias in your response to header-people comments is partially based on other inputs not part of the header-people discussion. If so, you guys ought to MAKE those other inputs part of the discussion, since header-people will otherwise be working at cross purposes and become somewhat irrelevant to your work. Major quibble: On the one hand, imminent commercial networks are way behind the (ARPAnet) state of the art, so we can't tell them to use out-of-channel communication of mail parameters, but on the other hand, they are hanging on our every word to find out how to organize their outdated system! You can't have it both ways. In fact, a commercial network should be in better shape than the Arpanet to get it together, since the programming is more likely to be done uniformly; if the Arpanet had nothing but TENEXes, life would be simpler albeit less fun. -------  Date: 10 Oct 1977 1039-EDT From: Philip Karlton at CMU-10A Subject: Slash dates To: Header-People at MIT-MC Sender: PHILIP.KARLTON at CMU-10A Message-ID: [CMU-10A] 10 Oct 1977 10:39:25 Philip Karlton In-Reply-To: [CMU-10A] 7 Oct 1977 19:50:22 Rick Gumpertz I am with Rick. Can we get rid of the slash dates along with the 12 hour times? PK -------  Date: 10 OCT 1977 1835-PDT Sender: DCROCKER at USC-ISI Subject: Re: Slash dates From: DCROCKER at USC-ISI To: PHILIP.KARLTON at CMU-10A Cc: Header-People at MIT-MC Message-ID: <[USC-ISI]10-OCT-77 18:35:30.DCROCKER> In-Reply-To: [CMU-10A] 10 Oct 1977 10:39:25 Philip Karlton OK, people. Slash dates have been removed. Dave. -------  Date: 10 Oct 1977 2204-EDT From: Brian Reid at CMU-10A Subject: Re: Slash dates To: Header-People at MIT-MC Sender: BRIAN.REID at CMU-10A Message-ID: [CMU-10A] 10 Oct 1977 22:04:13 Brian Reid In-Reply-To: <[USC-ISI]10-OCT-77 18:35:30.DCROCKER> Bravo!!!!!!!!! -------  Date: 10 Oct 1977 1953-PDT From: MRC at SU-AI (Mark Crispin) Subject: slash dates To: Header-People at MIT-MC what's more amazing, there was no fight about whether usa or european format should be used! how about flushing three letter abbreviations for month names? i can't see why we should have message id's and all that stuff (which i have not changed in my opposition to) and yet have sixbit halfword month names. -------  Date: 10 Oct 1977 (Monday) 2355-Est From: STECKEL at HARV-10 Subject: 3 ltr mon nms To: header-people at MIT-MC Ok, Mark, I think that the three letter month names are fairly standard usage, and though not pretty are certainly unambiguous. If people concur that they are ugly then away.  Date: 11 Oct 1977 0003-EDT From: Brian Reid at CMU-10A Subject: Month names To: Header-People at MIT-MC Sender: BRIAN.REID at CMU-10A Message-ID: [CMU-10A] 11 Oct 1977 00:03:06 Brian Reid In the olden days, when the act of checking a book out of a library consisted of signing a card and having a slip stamped, the due date was stamped in the back of the book and on the circulation card. The stamp used in many libraries used a TWO-letter month code, with no ambiguity. This two-letter code was pretty much universal. And even it was not totally ugly. But let's stick with the three-character names. Brian -------  Date: 11 OCT 1977 0013-EDT From: DLW at MIT-AI (Daniel L. Weinreb) Subject: Time zones To: STECKEL at HARV-10, header-people at MIT-MC Your header: Date: 10 Oct 1977 (Monday) 2355-Est From: STECKEL at HARV-10 Subject: 3 ltr mon nms To: header-people at MIT-MC contains a strange time zone; it seems you should either use the time zone you sent the mail from (EDT), the one you sent it to (PDT), or GMT...  Date: 11 Oct 1977 0102-EDT From: Philip Karlton at CMU-10A Subject: Day of Week To: Header-People at MIT-MC Sender: PHILIP.KARLTON at CMU-10A Message-ID: [CMU-10A] 11 Oct 1977 01:02:40 Philip Karlton Now that we got a couple of options out, how about allowing the day of week only in a comment in the Date: field. There is a formal proposal for a format for inserting additional text in most fields, (Are comments permitted in Message-IDs?) so why not use that instead of adding yet another syntax to be parsed? PK -------  Date: 11 Oct 1977 0106-EDT From: Brian Reid at CMU-10A Subject: Re: Time zones To: Header-People at MIT-MC Sender: BRIAN.REID at CMU-10A Message-ID: [CMU-10A] 11 Oct 1977 01:06:38 Brian Reid In-Reply-To: Your message of October 11, 1977 I bet we could go around on time zones, too. I spent several years working with programs to manipulate airline schedules, and time zones were a headache and a half. Some places stay on standard time all year around. Some go on daylight time. Outside the US, places don't convert back and forth with the same schedule. What does a mail program do if its user is sitting someplace that isn't on daylight time, but the host computer is. What about people who log on to MIT from the AMES tip? I don't think zones matter very much, but there might want to be a standard for what to do when the user is across the country from his host computer. I don't think that there are any ARPA sites yet in any of the places that don't go on Daylight time (parts of Indiana, Michigan, and Eastern Oregon). Do mail-header-generating programs have to know the fairly complex algorithm for determining whether it is Daylight time or Standard time? One solution is just to use local time, i.e. ELT, CLT, MLT, and PLT. This stresses the idea that the person who cares about the time must figure it our for herself. Another is to use GMT, which I think is a bad idea. And Mean Solar time is too hard to compute. Message-ID fields are the one place where GMT might be useful, actually. Since message-id's are so full of gobledygook, why not add more and buy unambiguity? Brian -------  From: Frankston at MIT-Multics (Robert M. Frankston) Date: 11 October 1977 0142-edt Subject: message-id's and GMT Message-ID: [MIT-Multics]1.2.BBBJGpdJNLPhcB To: brian.reid at CMU-10a cc: header-people at MIT-MC It is a fine idea to treat th message-id's as gobledygook. I am, however, opposed to putting GMT in ther because the less meaningful the message-id is the less people will be tempted to parse it ("but the message-id conains the date-time sent and the user-id so why not make that the only field" a justifiable (perhaps) statement in a Tenex-only world).  Date: 11 Oct 1977 0045-PDT From: MRC at SU-AI (Mark Crispin) To: Header-People at MIT-MC I may have a rotten mind, but the "local time" for the central area seems to have an obscene name (ie, CLT). -------  Date: 11 Oct 1977 0106-PDT From: MRC at SU-AI (Mark Crispin) Subject: time zones and all that To: Header-People at MIT-MC seriously, though (in reference to my last message; which by the way some bureaucrat just MIGHT see the relation and get moby upset--that sort of silly thing has happened you know), as for the day of the week field and time zones, will anybody's program actually parse that field? the only thing i've ever seen it used for is "in reply to ... message of ..." as an alternative to the message-id. getting the day of the week is not too bad although i can compute that fairly easily and it may be painful for some systems. what i find annoying is the random indentation and random spacing and random format of the date and time. some times the case hacking seems rather silly; like "Feb" or "Mar" and all that. if things are going to be "standard" why not decide on a true standard and have one format for the day and time? my personal preference is for "Date: October 11, 1977 1:14 AM PDT" although that format can't be used because of problems that have been discussed (disgustingly) before. but "Date: 11 OCT 77 0114-PDT" is alright or even "DATE: 11-OCT-77 0114PDT". just so long as there is one thing, and no unnecessary indentation for every thing. now, if it is unimportant what the times look like since nobody is going to parse them into some internal format, and you don't want to force people to use some format against their esthetics, then WHY ARE WE TALKING ABOUT TIME ZONES AND DAYS OF THE WEEK IF IT DOESN'T MATTER? let 100 flowers bloom the chairman said... really, isn't this asking for both ways? -------  Date: 11 Oct 1977 0135-PDT Sender: GEOFF at SRI-KA Subject: Re: time zones and all that From: Geoff at SRI-KA (Geoffrey S. Goodfellow) To: MRC at SU-AI Cc: Header-People at MIT-MC Message-ID: <[SRI-KA]11-Oct-77 01:35:33.GEOFF> In-Reply-To: Your message of October 11, 1977 If you don't like the way the date looks have your mail parsing/reading program make it look the way you want it too. I think the current format of times is just fine, in fact that is how I write dates myself by hand when required on dated documents, etc. -------  Date: 11 Oct 1977 0459-EDT From: Philip Karlton at CMU-10A Subject: Re: time zones and all that To: Header-People at MIT-MC Sender: PHILIP.KARLTON at CMU-10A Message-ID: [CMU-10A] 11 Oct 1977 04:59:13 Philip Karlton In-Reply-To: Crispin's message of October 11, 1977 RDMAIL, for one example program, does parse the date and time. It is used to sort the messages since they often arrive out of order due to things like host crashes, etc. Also, when messages are filed away, they are not always filed in the order received. This allows the user to get a history of some conversation with less work on his part. Why are you upset by leading or redundant white space? Case folding? The need for cononical time zones is so that a time can be parsed along with the date to allow the program to figure out what when (minutes since 1 Jan 1900 0000-GMT or whatever) some piece of mail was sent. PK -------  Date: 11 OCT 1977 0225-PDT From: MRC at SU-AI (Mark Crispin) To: Header-People at MIT-MC I'm sorry; perhaps I wasn't clear enough. I didn't mean to imply that dates were unimportant; I was asking if any program considered them as much other than a comment. I've been told that CMU's RDMAIL does. Fine. Then why not have one format for date/time specifications? The traditional way seems okay. Why should the mail reading programs be subjected to more work for no good reason? I really don't care about case; I was just saying that mixed case in an abbreviation of that type didn't really look good; but anyway, any reasonable program will convert and it is certainly not worth arguing about. Golly gee, I think the day of the week is nice and all that, but it doesn't serve me or any filing system I might write any good unless it occurs in all my incoming mail. If it is in just some of my mail it is part of the extra stuff that has to be ignored; I can't use it since it ain't always there. So is it really necessary? I apologize if the mail header comes out strange in this message. I am on a highly inferior terminal right now and SAIL does not handle these "glass teletypes" as well as it might; so I am sending it from MIT in a magic mode which may or may not work right. We'll see!!! Hey, why were we working? It was a holiday!!! Oh well. -- Mark  Date: 11 OCT 1977 0907-EDT From: GMP at MIT-MC (Gary M. Palter) Subject: time zones and all that To: MRC at SU-AI CC: HEADER-PEOPLE at MIT-MC For the record, the Multics read_mail program parses the date field in order to display the time at which a message was sent in local time for the user.  Date: 23 Oct 1977 1235-PDT From: Klh at SRI-KL Subject: Header standard draft To: Walker at ISI, Dcrocker at ISI, Pogran at MULTICS, To: Vittal at BBN, Henderson at BBN cc: Header-People at MC Could one of you inform the rest of us what is happening with the draft; I have not heard anything at all for too long. In particular, I have some more comments to make about a few questionable points, but will they do any good at this stage? I am also chafing because amid all this I have not had any whiffs about what sort of scheme you hav in mind for phasing a 724-like syntax into general use, despite several suggestions from the Header-people group, and that makes it hard to do any implementation planning. I don't care what the feedback is, as long as it exists. Even if there is trouble with certain sections that need more work, it is a much friendlier and more honest step to say so, instead of maintaining an ominous silence that invites misinterpretation. I am sorry to reiterate this but that is how I feel. --Ken -------  From: Frankston at MIT-Multics (Robert M. Frankston) Date: 28 October 1977 0206-edt Subject: Aside from 724 Message-ID: [MIT-Multics]1.2.BBBJGqqzdWBGpp To: header-people at MIT-MC even though 724 (or whatver it will be called) is being cast into concrete, there are still issues to be discussed in header people. One particular problem I have deals with internetworking. The complication is that the host system does not know that it is being involved in bridging two networks. In particular, Multics has a dial-out facility which I hope to use (when and if a bug or two is worked out in it) to transfer mail sent to Multics to the other system (call it the "ABC" system). The problem is that the mail to Multics should be addressed to an existing Multics user. Thus, as in the proposaed protocol: "Forwarder.Hack at MIT-Multics". The question is, where shoud I put the additional header information that Multics is not to see, but rather is to be interpreted by Forwarder when sending mail on to the outside system. I know there are many ways to do this such as adding nonstandard fields (allowable in the standard) or be encoding the information in the comment field of the address. Any suggestions out there for a reasonable way to do it that can be generally adopted? PS: Header-people has served as a general national bull-session. perhaps we should exlicitly create bull-session as a mailing list and expand its use to a larger popluation. Any takers?  Date: 28 Oct 1977 0254-EDT From: Brian Reid at CMU-10A Reply-To: Header-People at MIT-MC Subject: Bull session To: Header-People at MC Sender: BRIAN.REID at CMU-10A Message-ID: [CMU-10A] 28 Oct 1977 02:54:17 Brian Reid In-Reply-To: [MIT-Multics]1.2.BBBJGqqzdWBGpp I would like to see different groups set up. Bull-session might be too general. There are lots of topics that we might amongst ourselves feel passionately about, from personal computers to privacy to private-enterprise electronic mail to whatever. As long as it's within the scope of what the ArpaNet ought to be used for, I think it's a good idea and that some good might come of it. But---we probably ought not to clog up the MC mailer with a lot of this. Do any other sites have a facility like that? CMU is working on one, but it won't be up for a few weeks at the earliest (our mail implementor, a silent and female member of Header-People, who has been too busy working on our mailer to join much in these bull sessions, is working on it right now). Brian -------  From: Frankston at MIT-Multics (Robert M. Frankston) Date: 28 October 1977 0319-edt Subject: discussion groups. Message-ID: [MIT-Multics]1.2.BBBJGqwFflhFDC To: reid at CMU-10a cc: header-people at MIT-MC Ok, let's try to get a first approximation of such groups. trying to establish a separate one for each shade of interst would probably splinter things too much at this point. I agree with personal-computers as a topic that would attract some interst. I am not sure about privacy in that it is a vague term and includes all sorts of issues. Perhaps, however, we can do no better than the general term "privacy" for now. "electronic-mail" seems like a likely generalization of header-people and should specifically include nonARPA systems. Of course, computer people may, at first, tend to be like ham radio operators and get incestuous in their topics of discussion. I admit to not having a good idea of what noncomputer topics would be of interest to various groups, but such discussion groups would be interesting as a way to explore this medium without getting caught up too much in the medium itself.  Date: 28 Oct 1977 0027-PDT From: MRC at SU-AI (Mark Crispin) Subject: let's quit while we're ahead To: Header-People at MIT-MC Since most of the (vocal members of) Header-People are very opinionated (AND stubborn) and each with their own ideas about what is winning and what isn't (and many incapable of expressing their ideas in a way that fails to arouse hostility in the opposite camp) let's call it a day and sleep over it before jumping into more of this sort of thing! Oh yeah, I have some questions; and I would like some really well-thought-out answers. Basically they have to do with what Header-People was supposed to be all about. (1) Can the standard now be implemented on any system with mail facilities without depending on something unique to some operating systems? (2) Can a mail reading program which obeys protocol be written which will not choke on a message sent from a mail sending program obeying protocol for all cases allowed by the protocol? (3) Will such programs be able to handle minor violations of the protocol, as are bound to occur, and do the "right thing"? (4) Will a program which only processes the SUBJECT, TO, CC, and FROM lines be able to work without choking, assuming it ignores all header lines not in this set? (5) Has there been some thought for recommending limits to the number of header lines? In particular, consider the case of a 15 line mail header for a 1 line message, sent to a person reading his/her mail on a 10 CPS printing console using a reader which merely types the entire message out with no fanciness. This is a worse case combination, but one that has happened, many times. (6) Will existing programs using the old traditional "network" format (ie, the ancient Tenex SNDMSG version of mail headers) be able to work right (or work with the trivial modification of inserting in the host name for local users if the message is going out)? If not, how much work is involved? And finally,... (7) Is anybody EVER going to talk about a true mail protocol, with nice things like encryption (using the Rivest or similar method of course) and having all the header stuff as commands so everybody can see their mail using their own bad ideas, instead of somebody elses? The worst part about mail is that the receiver is stuck with what the sender gives him/her. With this I can have my one-line header and Fred.FooBAR @ FOO-SECURITY can have the phase of the moon and the last high tide in San Francisco Bay and both of us will be happy! Aiya Elenion Earendil Ancalima! Mark -------  Date: 29 Oct 1977 0744-EDT Sender: VITTAL at BBN-TENEXA Subject: Comments on the state of the world From: VITTAL at BBN-TENEXA To: header-people at MC Message-ID: <[BBN-TENEXA]29-Oct-77 07:44:02.VITTAL> Folks: Here is an interpretation of what has been put into 733, why, and some of the things which are planned for the future. It is highly unstructured, imprecise and not all-encompasing, so please bear with us. First of all, let me say that we understand the concerns voiced by many of the header people about the seemingly low level of responsiveness we (as the authors of the standard) have exhibited. Admittedly, we have not been communicating very well about all the points that have been discussed. However, it should be made very clear that we have spent a lot of time just reading, understanding, and sorting out all the header people comments, plus modifying the standard to reflect the new insight gained by the comments and the changes required, particularly when concensus finally was reached in the header people dialogue. Basically, there are a finite number of hours in a day and available for this task and we chose to focus on integrating everyone's ideas, to the extent that we could, rather than allocate the time to exhaustive responsiveness. As a rule, we would have liked to have been able to respond (remember: we are in the human communication business with these systems), but were in a resource-contention situation. The initial attempt was to take RFC680 plus what we felt were things which people were already doing that were useful to most, take out some things that weren't terribly useful and probably shouldn't have been in 680 in the first place, and come up with a new specification. There were several things that some systems were already doing: comments (e.g. the day of week in parentheses), association of people names with user names (like at places like Stanford, CMU and MIT, also using parenthesization), random date format preferences (Multics vs Tenex, etc.), and so on. Elements of 680 which were not perceived as necessary were mostly the military-like field names such as precedence, as well as syntactic inconsistencies (bugs), and syntactic limitations. These could all be accomplished by using the notion of user-defined fields. This "interim" effort was intended to be just that -- something to hold us until a real structured protocol was funded and developed (Haverty's effort is an example of what might be used as a structured protocol). Another driving function was that nobody should be forced to modify the mail delivery code (on Tenex, that is FTP and MAILER). Only the mail creating and reading code should be modified. Let me get down to some specifics. First of all, many people wanted the facility to include arbitrary comments in fields, and have them understood as that syntactically. In addition, there was the feeling that people names should be associated with mailboxes. Also there should be the notion of "machine understandable" versus "straight" text. The coupling of these three notions together caused a lot of haggling; we finally came up with a syntax that met most of these criteria: comments are parenthesized entities, machine understandable quantities were included in angle brackets ("<>"), usually. Syntactically, addresses are either machine understandable quantities (similar to the address format being sent around the network today), or straight text followed by machine readable data. That was the initial attempt at 724. Most of these criteria are still relevant (although generalized), some of the multiplicity (complications?) has been removed; but, in spirit, the standard as it currently stands remains basically the same as it was originally conceived. Many people want to add other things: encryption, privacy, more general structure to addresses to fit what MIT is currently doing with parenthesized addresses, and so on. Others wanted to get rid of a lot of requirements (note that Message- Id's are NOT required) and turn the standard into a specification for the MINIMUM necessary to get a job done (one must understand what the job is first; these ended up, most often, being personal requirements rather than an attempt to satisfy the larger set of problems that commercial users will have). Some of these belong in some document (such as an extension to the standard), others don't belong in the document at all (encryption, privacy, heuristics for determining a message-id if one is not explicitly specified in a particular message, and so on), and still others do (syntax for optional fields in active use such as message-id's, etc.). Which fields and options to included in the standard and which not to include were driven partially by what people (message system users) are doing right now in their jobs (actual user requirements) and what they expect out of message services. We are NOT driven by the hackers world that we would like to be driven by and basically consider ourselves a part of (after all, there are far fewer constraints in that world), but rather the users in various organizations. So, in the end (since we are close to it), we should elucidate some of the final decisions and remaining loose ends, and where we would like to go from here. Encryption: not included -- this is a standard for the syntax of message headers and little else; encryption doesn't really belong there. Adoption dates: they haven't yet been specified by ARPA. They will be appended to the standard as soon as they are known. Probably somewhere around the beginning of February or March is when it should happen. People vs. user vs. groups: all could be done with only one syntax. However, that won't express the expected sets of semantics which is why we have <> (for mailboxes) and ;: (for groups). There was a time when the syntax actually had [] reserved and used in place of <>, but it was felt that [] occurred more often in real text. Now, as an extension, addresses could be made to look like MIT's with the inclusion of the structured info being passed to FTP being bracketed rather than parenthesized. It can be accomplished right now using quoted strings; however, that solution won't recognize the well- nestedness of brackets. This extension will probably come, but after a fair amount of discussion. No explicit extensions will be mentioned at this time in the standard itself. Dates: well, that's been beaten past the point of death and burial. Addresses and nesting: things like "<<>>" and "frob at bar >" in fact are legal. The meaning (i.e. semantics) are not especially obvious and are somewhat hard to interpret. The bottom line is that the specifications each resolve to mailbox "foo at bar" where the rest of the information is really just text to be interpreted as effectively individual description if you'd like. The problem with this is that we don't expect message systems to generate stuff that looks like this, since it is rather unclean, but instead to use the more intuitive form, probably eliminating the middle level (fie at bar). What gets passed to FTP. Let me express our intentions by giving an example: To: foo at fie, J. D. Rockefeller at foe, "Jimmy(the Greek)" at fum causes the message to be sent to - "foo" - "J. D. Rockefeller" - "Jimmy(the Greek)" Note there is ONLY ONE space between "words" regardless of the amount of white space in the unfolded version of the address. Surrounding double quotes (if the address type is a quoted string) are NOT sent -- there is no need to. Finally, just a short note on requirements vs. options. The only requirements are that certain fields be included (From or From plus Sender, and Date). Note that EVERYTHING else is OPTIONAL. However, all additional fields which are included MUST adhere to the syntax specified in the standard. That includes the text, addresses, subjects, and so on. We should note that this document is going to be placed in the next issue of the Network Protocol Handbook being prepared for publication in the imminent future. This has been one of the driving functions in our attempt to finish the standard. Therefore, if you do wish to send in comments about the standard, please feel free. Understand, however, that we will consider everything, but don't necessarily have the time to respond to each individual suggestion or complaint; this has been the case in the past and will continue, we are sorry to say. John Vittal (for the authors of 733) -------  Date: 29 Oct 1977 1054-EDT From: Rick Gumpertz at CMU-10A Subject: Re: Comments on the state of the world To: VITTAL at BBN-TENEXA CC: header-people at MC Sender: RICK.GUMPERTZ at CMU-10A Message-ID: [CMU-10A] 29 Oct 1977 10:54:07 Rick Gumpertz In-Reply-To: <[BBN-TENEXA]29-Oct-77 07:44:02.VITTAL> Where is there a copy of the CURRENT text that we can read?? In your example of "Jimmy(the Greek) at mumble", would it be leagl to give FTP the names "Jimmy" or "Jimmy(the Greek)"?? Rick -------  Date: 29 OCT 1977 1539-EDT From: RMS at MIT-AI (Richard M. Stallman) Subject: "Jimmy(the Greek)" To: header-people at MIT-MC Since this address was enclosed in quotes, the parentheses do not form a comment, and are part of the actual address. However, what bothers me is that surrounding quotes are not supposed to be sent. This has the consequence that one can't distinguish the addresses [BUG FOO] and "[BUG FOO]". Not sending the quotes is fine when the only syntactical characters one might need to quote are normally processed before handing the names to the FTP server. But when there are special characters that are special because of how the FTP server treats them, one must be able to pass the quotedness along somehow. And what happens to an address like John "Foo@Bar" @ ai or [BUG "@"] @ AI (we are actually going to need this! We have a program named "@". Right now we use "(BUG @)" and recognize that the @ is part of the address because it is inside the parens). or [FILE "RMS;FOO] BAR["] @ AI where the inner quotes are needed to show the FTP server how the brackets balance?  Date: 29 OCT 1977 1701-EDT From: MOON at MIT-MC (David A. Moon) To: HEADER-PEOPLE at MIT-MC I think the answer to RMS's question/complaint about quoting in addresses is supposed to be that the argument to the MAIL (or MLFL) command of the ftp protocol is assumed to be quoted, that is no special characters are to be looked for in this argument, except for the carriage return that terminates it. I have never seen this explicitly stated anywhere. I think it belongs in RFC 733, in as much as the RFC has a lot to say about addresses and the FTP protocol is what "implements" addresses from the point of view of RFC 733. I hope this is not interpreted to mean that structured addresses may not be used with FTP. That is, when mail is sent to `"Jimmy(the Greek)"' the outer quotes are stripped off, and mail is sent to the person (mailbox) named `Jimmy(the Greek)', but when mail is sent to `[FILE "rms;]foo >"]' the FTP is allowed to notice the square brackets, and the inner quotes are not stripped. It's clear that the quoting notion is still very vague, and is not going to work for things like Rigellian users with brackets and double quotes in their surnames. But the RFC should at least explicitly state what is being assumed.  Date: 29 Oct 1977 1726-EDT From: Philip Karlton at CMU-10A Subject: Preferred address format To: Header-People@CMU-10A Sender: PHILIP.KARLTON at CMU-10A Message-ID: [CMU-10A] 29 Oct 1977 17:26:57 Philip Karlton Hopefully this is a simple question. Which is the preferred way to send addresses in the header. It is hoped that all the following will cause the same text to be sent to the FTP servers. a) PK01 at CMU-10A (Philip L. Karlton) or b) Philip L. Karlton Is it true that if form a) is used then the mail reader/composer may feel perfectly free to flush the (Philip L. Karlton) from header it is composing in doing a reply? PK -------  Date: 29 Oct 1977 1730-EDT From: Philip Karlton at CMU-10A Subject: Re: quoting To: Header-People@CMU-10A Sender: PHILIP.KARLTON at CMU-10A Message-ID: [CMU-10A] 29 Oct 1977 17:30:41 Philip Karlton In-Reply-To: Moon's message of October 29, 1977 It was my understanding that the names that are put into the headers by the composing program be something that is acceptable by the FTP server. It is between the composer and the server to negotiate what strings (as long as they are quoted in the header or brackets balance) are considered legitimate targets for mail. PK -------  Date: 29 Oct 1977 1504-PDT From: Geoff at SRI-KA (Geoffrey S. Goodfellow) Subject: Re: Preferred address format To: Header-People at MIT-MC Message-ID: <[SRI-KA]29-Oct-77 15:04:53.Geoff> In-Reply-To: [CMU-10A] 29 Oct 1977 17:26:57 Philip Karlton I prefer choice A: PK01 at CMU-10A (Philip L. Karlton) For two reasons: (1) This format is more or less a de-facto standard already around the net, lots of sites use it as a way of including the senders full name in the header. (2) a LOT of systems are not going to have 'personell name' database files like MIT, SAIL, CMU, SRI do which can be accessed by the mail program, hence, it is much easyer to just leave the (Philip L. Karlton) off on the end of the message, rather than: appearing on the FROM line. [Geoff] -------  Date: 30 OCT 1977 0028-EDT From: MOON at MIT-MC (David A. Moon) Subject: Clogging up MC mailer (Re: Brian Reid) To: HEADER-PEOPLE at MIT-MC Maybe big mailing lists like Header-People and Bullshit-People should be handled the way LSC* movie announcements are handled now: the mailing list consists of several secondary mailing lists at other hosts, and then the load is distributed. If there are 3 CMU hosts and 4 MIT hosts that can do distribution, it might not be too bad. Really need at least one on the West Coast, though. --- *LSC: An MIT organization which shows (mostly) 35mm movies, (mostly) 3 per weekend, for the MIT community, for a fairly reasonable price. The acronym is Lecture Series Committee, you should be able to figure it out.  Date: 29 Oct 1977 2132-PDT From: BH at SU-AI (Brian Harvey) Subject: Forwarder on west coast To: header-people at MIT-MC SAIL's FTP server will accept MAIL commands with arguments in the form @FILE to use the (local SAIL) file named FILE as a mailing list. Of course, if you want to set up such a hack, you need access to a file directory here. Also, I'm not sure the management would take kindly to that use of our too-busy computer. Nevertheless, the feature exists. -------  Date: 30 OCT 1977 1437-PST Sender: DCROCKER at USC-ISI Subject: Double-quotation marks in address names From: DCROCKER at USC-ISI To: header-people at MIT-MC Message-ID: <[USC-ISI]30-OCT-77 14:37:58.DCROCKER> They can be included simply by doubling them. Ergo, "Mack (the knife)" at cutthroat-u has """Mack (the knife)""" passed to cutthroat-u's ftp server. The most current version of the specification is in [isia]standard.draft and can be retrieved by logging in with user=anonymous and pass=anything. Dave. -------  Date: 30 OCT 1977 1842-EST From: RMS at MIT-AI (Richard M. Stallman) To: Dcrocker at USC-ISI, header-people at MIT-MC So do you intend "John Brown" and John "Brown" to be indistinguishable as addresses? That won't do at all for structured addresses, where [BUG "FOO]"] must not be the same as [BUG FOO]], which is meaningless. So we will probably not strip off doublequotes that surround only a part of the address.  Date: 30 OCT 1977 1556-PST Sender: DCROCKER at USC-ISI From: DCROCKER at USC-ISI To: RMS at MIT-AI Cc: header-people at MIT-MC Message-ID: <[USC-ISI]30-OCT-77 15:56:30.DCROCKER> In-Reply-To: Your message of OCTOBER 30, 1977 This is getting frustrating. How do you guys put quote-marks in literal strings in languages like PL/1? YOU DOUBLE THEM. When the string is reproduced only they come out in SINGLES. if you have the address "Mack the knife" then, in an address conforming to the new specification, you would have """Mack the knife""" and, when taking the address and passing it to some "outside" process, such as ftp servers, you pass "Mack the knife". It does not matter where the quote marks (as data) are in the string. If the name were Mack "the knife" then the string is included as "Mack ""the knife""". YOU ONLY STRIP OFF THE DELIMITING (ie., beginning and ending) QUOTE MARKS AND REDUCE THE DOUBLED ONES TO SINGLE ONES. ThisThese are extremely standard string-processing conventions. Dave. -------  Date: 30 Oct 1977 1837-PST From: MRC at SU-AI (Mark Crispin) Subject: DIALnet mail formats To: Header-People at MIT-MC With the completion of the first version of the DIALnet host-host protocols, my attention has returned to the subject of DIALnet mail. I solicit your suggestions for the design of a mail protocol. As of this writing, there are two theories as to how it should be done. In either case, the ARPAnet way of doing things (as a command to the file transfer protocol with the information in a mail header) has been rejected. My concern is to have a single protocol which will be satisfactory for both "smart" and "dumb" mailing systems. A "dumb" mailing system is a bare bones system which "does the job". A "smart" mailing system has extra hairy features. Every mail system has to be able to be "dumb", but if both are "smart" about something they can use it. The first theory makes MAIL much like the ARPAnet FTP protocol. A sample command would be something like this: MAIL: TO : MRC FROM: MRC @ (415)-497-5505 MSG : This is a test.  Date: 30 Oct 1977 1850-PST From: MRC at SU-AI (Mark Crispin) Subject: DIALnet mail formats To: Header-People at MIT-MC, JMC To those who got part of this message before, I apologize. SAIL's mail user program cleverly uses MAIL instead of MLFL and a line with only a dot in it terminates the message. With the completion of the first version of the DIALnet host-host protocols, my attention has returned to the subject of DIALnet mail. I solicit your suggestions for the design of a mail protocol. As of this writing, there are two theories as to how it should be done. In either case, the ARPAnet way of doing things (as a command to the file transfer protocol with the information in a mail header) has been rejected. My concern is to have a single protocol which will be satisfactory for both "smart" and "dumb" mailing systems. A "dumb" mailing system is a bare bones system which "does the job". A "smart" mailing system has extra hairy features. Every mail system has to be able to be "dumb", but if both are "smart" about something they can use it. The first theory makes MAIL much like the ARPAnet FTP protocol. A sample command would be something like this: MAIL: TO : MRC FROM: MRC @ (415)-497-5505 MSG : This is a test. . END : The server reads these commands (which are canonical card-image type things) and delivers the message with whatever header is desired. The only thing required is the TO entry. Everything else is optional! The only thing that is attractive about this design though is that it could be written in any sort of bad environment; it is a trivial FORTRAN program for example. The second theory (and the one that is getting more attention around here) is a LISP-like mail format. The advantages to using a LISP-like syntax are numerous, since it allows not only the removal of all sorts of quoting and ambiguity problems, but it also is easy to parse S- expressions. That test message above would look like: (MAIL (TO MRC) (FROM MRC (PHONE (415)-497-5505)) (MSG (This is a test.))) We are wondering if any site would have difficulty in writing software that could parse S-expressions, and if so, we would like a detailed explanation of why it would be difficult. Please note that this is not a protocol specification. There are still many other things that have yet to be decided upon. It's only to express the general idea. Mark -------  Date: 30 OCT 1977 2308-EST From: RMS at MIT-AI (Richard M. Stallman) To: header-people at MIT-MC Well, we now all know what to do with "[BUG ""FOO]""]", if we didn't already. Meanwhile, with [BUG "FOO]"], the thing to do is not strip out the quotes, but pass it as is. [BUG "FOO]"] @ AI is to "[BUG ""FOO]""]" @ AI as Brown @ AI is to "Brown" @ AI; namely, it is an unnecessary use of duoblequoting which obscures what is going on.  Date: 31 Oct 1977 1034-EST Sender: HENDERSON at BBN-TENEXD Subject: Re: "Jimmy(the Greek)" From: HENDERSON at BBN-TENEXD To: RMS at MIT-AI Cc: header-people at MIT-MC Message-ID: <[BBN-TENEXD]31-Oct-77 10:34:36.HENDERSON> In-Reply-To: Your message of October 29, 1977 733 contains a convention for including the double-quote character in quoted strings: double it. Thus "abc""def" is a seven-character string the fourth character of which is a double-quote. Other than double-quote, quoted text can contain any characters at all (see productions for quoted-string and qtext). As to the assumptions made by various FTP server and user programs, I am pretty sure we don't fare as well. Possibly NOW is the time to get together another RFC for the "mail" aspects of the FTP protocol. Austin -------  Date: 31 Oct 1977 1302-EST From: JHAVERTY at BBN-TENEXE Subject: Re: "Jimmy(the Greek)" To: HENDERSON at BBN-TENEXD, RMS at MIT-AI cc: header-people at MIT-MC, JHAVERTY In response to the message sent 31 Oct 1977 1034-EST from HENDERSON at BBN-TENEXD Austin, The convention of putting double-quotes in a string by doubling them is a little more complex than it seems, I think. If you do this, a string is no longer defined as a stream of characters enclosed in double-quotes. Rather, the syntax must specify that there be another delimiter on each end, to protect the double-quote in case the adjacent element is also a string. i.e. "abc""def" and "abc" "def" are different only because of the white-space between them. This has always bothered me a little because of the syntax itself, but the real hassle is a programming one. Consider a program which generates the text stream. You can no longer have a program which simply outputs a string enclosed in double-quotes. Rather, some program must know what preceeds and what follows the string, and must make sure there is an appropriate break character such as a space to separate successive strings. It seems like there might be a problem in being forced to put in a space, for example, which isn't intended to be in the output, but must be put in to separate adjacent strings. Maybe this is easy to circumvent, but I think the spec should at least include a warning about the potential problem, since it may impact on how parsers and printers are structured. Jack -------  From: Frankston at MIT-Multics (Robert M. Frankston) Date: 31 October 1977 1304-edt Subject: quoting Message-ID: [MIT-Multics]1.2.BBBJGwHhlDDjpg To: header-people at MIT-MC The double quoting problems are quite apparent in the Multics command processor which retains the PL/I double quoting convention. The basic problem is that PL/I has an explicit contatenatain character while the command processor (and mail headers) have implicit concatenation by juxtapositioning. (or do they, must you quote a whole token if you quoe any part of it and separate it from other toeksn with white space?). In any case this is one of the reasons I prefer the quoting convetion used in languages like BCPL which has a special marker within quoted strings to indicate the disposition of the next character. Thus one could have the convention that ~ (to use my previous example) is the escape within quoed strings for example: "strange~"name" Preferable to this, and easier to parse on naive systems might be "strange~qname" where ~q means quote. Of course mail sending programs need to know how to parse this, but receivers need not. Once one has such an escape, the ~n for newline and other such special conventions are supported. Oh yes, ~~ would be a single ~. This is safer than "" since it is not really a doubled tilde, but a tilde followed by a tilde, a significant difference to the parser.  From: Frankston at MIT-Multics (Robert M. Frankston) Date: 31 October 1977 1310-edt Subject: " Message-ID: [MIT-Multics]1.2.BBBJGwHjDwWGkZ To: header-people at MIT-MC On final problem with " is that " , ^ ' ` have alternate uses as accent marks. This causes problems when one looks at single ascii characters rather than graphic positions (defined by a sequence if single ASCII character separated by backspaces). How does one send mail to Hans M"uller?  Date: 31 Oct 1977 1348-EST Sender: HENDERSON at BBN-TENEXD Subject: Re: "Jimmy(the Greek)" From: HENDERSON at BBN-TENEXD To: JHAVERTY at BBN-TENEXE Cc: header-people at MIT-MC Message-ID: <[BBN-TENEXD]31-Oct-77 13:48:43.HENDERSON> In-Reply-To: Your message of October 31, 1977 Jack: Yes, I know the problem; we use this convention in Hermes. On input (parsing), the RFC covers the issue under lexical analysis. The rules for that task are made clear. (One of the reasons why SPECIALS are specials everywhere rather than just where they are needed is to separate lexical and syntactic analysis, and that is done just so that this question of when a string stops is easy to answer. On output (message generation): the RFC permits spaces anywhere except in the "middle" of an atom (that is, two atoms cannot be concatenated without a space between them (again to make lexical analysis possible). In particular, following a string a space is always legal. So generation can be pretty easy. However, such simple processing can lead o unnecessary spaces, and that may not be too aesthetically satisfying. In that case, the "higher level" outputter would have to do the work which you suggest. That outputter can be thought of as a "lexical synthesizer", putting out things which the lexical analyzer at the receiving end will be able to analyze. Austin -------  Date: 31 Oct 1977 1403-EST From: Philip Karlton at CMU-10A Subject: Standard.Draft and Message-IDs To: Header-People@MIT-MC Sender: PHILIP.KARLTON at CMU-10A Message-ID: [CMU-10A] 31 Oct 1977 14:03:51 Philip Karlton Either I have misread the standard or I have missed some point. As near as I can tell, all Message-IDs must be surrounded by <>. Why? Why is only a mach-id allowed inside. That means that special characters (like ":") cannot be in a Message-ID unless they are in a quoted part of a phrase. It seems to me that a good enough interpretation for a Message-Id would be any string of characters up to the , not allowed to be broken accross line boundaries and leading and trailing LWS not considered to be part of the string. PK -------  Date: 31 Oct 1977 1439-EST From: JHAVERTY at BBN-TENEXE Subject: Re: "Jimmy(the Greek)" To: HENDERSON at BBN-TENEXD cc: header-people at MIT-MC, JHAVERTY In response to your message sent 31 Oct 1977 1348-EST Austin, It sounds like the syntax handles the problems. The question at this point seems to be what the advantages of the 'doubling' system are, to outweigh the need for programming a 'lexical synthesizer', and living with apparently-extraneous whitespace at times. It seems like the quote-charachet convention (Frankston's tilde or some such character) is no more or less obnoxious in appearance, but simpler to handle in the programming. Jack -------  Date: 31 Oct 1977 2139-EST From: Rick Gumpertz at CMU-10A Subject: : in times To: Header-People@MIT-MC Sender: RICK.GUMPERTZ at CMU-10A Message-ID: [CMU-10A] 31 Oct 1977 21:39:52 Rick Gumpertz Are the two colons in 6-digit times tied?? I.e is 23:1111 legal?? What about 0023:11?? Rick -------  RMS@MIT-AI 10/31/77 21:48:05 0023:11 should be allowed. Suppose someone basically likes the form HHMM, but wants to put in seconds for purposes of disambiguation. The form HHMMSS is a little hard for people to parse, so HHMM:SS is the only possibility.  Date: 31 Oct 1977 2227-EST From: Rick Gumpertz at CMU-10A Subject: RFC 733 To: Header-People@MIT-MC Sender: RICK.GUMPERTZ at CMU-10A Message-ID: [CMU-10A] 31 Oct 1977 22:27:43 Rick Gumpertz RFC 733 seems to be stabilizing. Besides, the new ARPANET protocol handbook is due someday soon. I strongly feel that before 733 gets any sort of stamp of "official approval" as a standard, it should be implemented and used by at least a few sites. Design problems have a way of becoming more obvious when one tries to really implement the paper design. Does anyone out there have the time to get a 733 like mail sender/receiver running? Has anyone tried yet? Rick -------  Date: 31 Oct 1977 2238-EST From: Rick Gumpertz at CMU-10A Subject: re 0023:11 To: RMS@MIT-AI CC: Header-People@MIT-MC Sender: RICK.GUMPERTZ at CMU-10A Message-ID: [CMU-10A] 31 Oct 1977 22:38:54 Rick Gumpertz In-Reply-To: Your message of October 31, 1977 All I can say is that mail parsers will have to be careful to not confuse 0023:11 with 23:11. If the colons are tied (i.e. both or neither must appear) things would be less prone to error, although 002311 might still be confsed with 2311. Note, however, that nobody in the real world (to my knowledge, which is very limited in this case) uses six digit times without punctuation. Perhaps, therfore, we should allow only HHMM, HH:MM, and HH:MM:SS. I really don't care and would just as soon allow all possible combinations, but parser-writers should beware the pitfalls! Rick -------  RMS@MIT-AI 10/31/77 23:45:37 If anyone wants to see a parser that can distinguish hh:mm and hhmm:ss, look in SYSENG;DATIME > on MIT-AI. It is very easy; just see how many digits are in the first number. hh and hh:mm:ss are also allowed (though not hhmmss). RHG, you say that you can easily allow for both alternatives, but then you argue based on the difficulty. That seems inconsistent.  Date: 1 Nov 1977 0251-EST From: Philip Karlton at CMU-10A Subject: DCrocker response to [CMU-10A] 31 Oct 1977 14:03:51 Philip Karlton To: Header-People at MIT-MC Sender: PHILIP.KARLTON at CMU-10A Message-ID: [CMU-10A] 1 Nov 1977 02:51:22 Philip Karlton I think this belongs in the records. PK Begin forwarded message - - - - - - - - - Date: 31 OCT 1977 1508-PST Sender: DCROCKER at USC-ISI Subject: Re: Standard.Draft and Message-IDs From: DCROCKER at USC-ISI To: PHILIP.KARLTON at CMU-10A Message-ID: <[USC-ISI]31-OCT-77 15:08:46.DCROCKER> In-Reply-To: [CMU-10A] 31 Oct 1977 14:03:51 Philip Karlton Requiring <> around Message-ID data, when it obviously doesn't have to be required, for that field, was chosen to be compatible with EVERY other situation in the standard when the angle-brakcets really are needed, such as In-Reply=to. If we do not require the angle-brackets, then Message-ID would really be the exception, syntactically! Dave. ------- End forwarded message -------  Date: 1 Nov 1977 1041-EST From: Rick Gumpertz at CMU-10D Subject: colons in times To: RMS@MIT-AI CC: Header-People@MIT-MC Sender: RICK.GUMPERTZ at CMU-10D Message-ID: [CMU-10D] 1 Nov 1977 10:41:55 Rick Gumpertz RMS - I was not saying that the various formats were hard. I was simply pointing out the possible pitfalls which might encounter the implementer. I have seen TOO many programs which do not handle things like this correctly to believe that noone would get trapped. Rick -------  Date: 1 Nov 1977 1047-EST From: Rick Gumpertz at CMU-10D Subject: <> around MSG IDS To: Dcrocker@Rand-Unix CC: Header-People@MIT-MC Sender: RICK.GUMPERTZ at CMU-10D Message-ID: [CMU-10D] 1 Nov 1977 10:47:06 Rick Gumpertz If <...> is always required, then why is there the special emphasis on needing them in "In-reply-to" fields?? By the way, are angle brackets otherwise prohibited in that field?? If not, how can a program decide if it indeed has a MSG-ID? Also, ":" is prohibited in MSG-IDs, because it is a special. This would seem to prohibit colons in times which appear in msg-ids. This seems like it will only serve to make msg-ids less readable. Rick -------  Date: 4 Nov 1977 at 1601-PST Subject: Deadline for the Specification From: Dcrocker at Rand-Unix To: Header-People at Mit-Mc Message-ID: <[Rand-Unix] 4-Nov-77 16:01:54.Dcrocker> We have now been given a November 21 deadline for submitting the mail syntax specification to be published in the Arpanet Protocol Handbook. Since we will need some time to finish dotting i's and crossing t's, I believe we can continue to process comments from Header-People as late as November 10. The latest draft is, as usual, in [isia]standard.draft and can be retrieved by using ftp with a login of user=anonymous and pass=anything. With respect to quoting, I am personally leaning towards keeping the current scheme and NOT introducing a quote-next-character mechanism. However, this will require adding some important cla- rifications to a few places in the spec. Note that I said "per- sonally". Others on the committee may yet outvote me, so well- formed arguments from y'all may overpower my bias. Any other unclear items that any of you are noticing in the docu- ment? Dave.  From: Frankston at MIT-Multics (Robert M. Frankston) Date: 4 November 1977 2100-est Subject: quoting Message-ID: [MIT-Multics]1.2.BBBJGwbhcbDjGQ To: header-people at MIT-MC A question. One of the reasons that I originally proposed my escaping convention (a clearer term than quoting for "~") was to allow the inclusion of special characters such as newlines in a string without making the parser hairier (except in the few cases where it is actually interested in internal parsing of a quoted string). Is this need met by other mechanisms in the proposed standard?  Date: 4 Nov 1977 2225-EST From: Philip Karlton at CMU-10A Subject: Message-ID's, :'s and <>'s To: Header-People at MIT-MC Sender: PHILIP.KARLTON at CMU-10A Message-ID: [CMU-10A] 4 Nov 1977 22:25:35 Philip Karlton May I please have some sort of response to the questions I sent out last week? PK -------  RMS@MIT-AI 11/05/77 20:22:49 To: HEADER-PEOPLE at MIT-AI I have never been able to understand what purpose is served by allowing spaces between a field name and the following colon, or by allowing multiple spaces within the field name to be equivalent to single spaces. Does anyone have an application for this that I haven't imagined? I would appreciate hearing from anybody who plans to use this feature. My mail-reply program is written in TECO, and CANNOT use the lexical analysis scheme which is suggested in 733. Recognizing TO : as equivalent to TO: would cause a significant slowdown. I think my users would rather have mail containing TO : be misparsed.  Date: 6 NOV 1977 1635-PST Sender: DCROCKER at USC-ISI Subject: spaces in field-names From: DCROCKER at USC-ISI To: header-people at MIT-MC Message-ID: <[USC-ISI] 6-NOV-77 16:35:19.DCROCKER> The philosophy behind allowing multiple spaces is simply that it seems extraordinarily unfriendly not to allow them. I could refer to real-world situations in which people carefully align the column colons occur in, so that there is variable spacing between the last "label" word and the colon, but I'd rather not do that... Dave. -------  Date: 6 NOV 1977 1708-PST Sender: DCROCKER at USC-ISI Subject: Re: Message-ID's, :'s and <>'s From: DCROCKER at USC-ISI To: PHILIP.KARLTON at CMU-10A Cc: Header-People at MIT-MC Message-ID: <[USC-ISI] 6-NOV-77 17:08:12.DCROCKER> In-Reply-To: [CMU-10A] 4 Nov 1977 22:25:35 Philip Karlton First of all, you DID get a response to the questions you raised within Header-People. I sent you a response, which you then chose to forward to header-people. You then iterated the questioning, back to me privately. Your second iteration was incomprehensible to me, referring to such things as double-angle brackets being required for Message-ID's in In-Reply-To fields (...They aren't) and complaining about only being allowed to put message-ids in the brackets. I am not clear what else you want to put in them, nor am I clear why it is not adqequate to put them in the "phrase" which is the alternate construct permissible in In-Reply-To fields. Oh, yes. You also indicated that what we had would imply that angle-brackets would have to be delimiters. Well, you're right. That is why they are in the list of specials which is defined to be a member of the set of delimiters. The only other question which you've asked, that I know of, had to do with "address (name)" versus "name
" and which was the preferable construction. I have a fairly strong memory of writing a lengthy reply indicating that the latter would allow the syntax to distinguish the semantics of naming and that the former would mean that the parser couldn't tell if a name or any other random comment was being. used. Were there any other points pending? Dave. -------  Date: 6 Nov 1977 2151-EST From: Philip Karlton at CMU-10A Subject: Re: Message-ID's, :'s and <>'s To: DCROCKER at USC-ISI CC: Header-People at MIT-MC Sender: PHILIP.KARLTON at CMU-10A Message-ID: [CMU-10A] 6 Nov 1977 21:51:19 Philip Karlton In-Reply-To: <[USC-ISI] 6-NOV-77 17:08:12.DCROCKER> I'll try again, and this time I'll try and be a little more explicit. I see two minor problems in RFC733 that should be cleared up before it gets published. 1) A message-id is only allowed to be of the form < phrase @ host-indicator > This implies to me that a message-id can no longer have ":"s in them (unless of course they are quoted) since ":" is considered a special. Is it really your intention to disallow the message-id's that I seem to get from most Tenex sites? 2) On page 20, the paragraphs IV.B.2 and IV.B.3 contain the sentence "If message identifiers are used, they should be enclosed in angle brackets (<>)." Since message identifiers are already defined to contain <>s, this seems redundant. This is the place that I got thrown off and thought that double angle-brackets were being requested. I overlooked the syntax for optional-field that showed that the "In-Reply-To" field was really a mach-id and not "<" mach-id ">". It would be a good idea to replace the above sentence in IV.B.2 and IV.B.3 with a recommendation that <>s not be placed in the described fields unless they (the <>s) were part of a message identifier. I apologize for not making myself more clear the first time. PK -------  Date: 7 NOV 1977 0036-EST From: RMS at MIT-AI (Richard M. Stallman) To: HEADER-PEOPLE at MIT-AI The reason to forbid the spaces between field names and colons is to make it easier for extremely simple programs, or programs on which there are unavoidable constraints (such as TECO macros), to parse headers. As I've said, my mail-reply program is in any case not going to be able to handle such spaces. So if people want their mail to be parsable on AIMLMC, they will have to avoid using such spaces. Of course, sites that don't communicate with AIMLMC very much might well not care whether we could parse their mail; it is their choice in any case. If they really wanted to use extra spaces, that desire would outweigh the lossage. But it seems that nobody has any real desire to put extra spaces in those places, and that no one would actually be unhappy if they were forbidden. If anyone ever uses them it will probably be just "because they are there". So why not forbid them and avoid lossage?  Date: 7 Nov 1977 1243-EST From: Brian Reid at CMU-10A Subject: Re: To: RMS at MIT-AI (Richard M. Stallman) CC: Header-People at MIT-MC Sender: BRIAN.REID at CMU-10A Message-ID: [CMU-10A] 7 Nov 1977 12:43:54 Brian Reid In-Reply-To: Your message of November 7, 1977 Your message borders on blackmail. It's this very sort of narrowmindedness, originally on the part of the TENEX mail systems, that makes us need a standard even more. If you can't parse mail that I send to you, and my mail is an standard format, that's your problem and not mine. If you choose to write your mail-answering program as a TECO macro and then bitch because it isn't good enough, then that's your problem, and not ours. Spaces in mail headers are one of those human-factor things that ought to be present unless there is a very good reason to specifically exclude them. And the inability of somebody's TECO macro to parse them is not a reason. -------  From: Frankston at MIT-Multics (Robert M. Frankston) Date: 7 November 1977 1247-est Subject: TECO Limits Message-ID: [MIT-Multics]1.2.BBBJGwkPQLxNlC To: header-people at MIT-MC And since Stallman maintains TECO .....  Date: 7 Nov 1977 0948-PST From: MRC at SU-AI (Mark Crispin) To: Header-People at MIT-MC I see the name calling has started again. Why can't RMS complain about such a formatting problem which the standard introduces? Doesn't this complaint has as much validity as the ones about tabs that the Multics people made? Or the problems that were brought up by the CMU people (I forget exactly; but the CMU'ers told me that if a suggestion I made was implemented it would screw their RDMAIL program such that they couldn't fix it)? Or is it because MIT's RMAIL is written in TECO? Frankly, I am tired of wisecracks about people who use TECO. -------  Date: 7 Nov 1977 1329-EST From: Rick Gumpertz at CMU-10A Subject: TECO and parsing To: RMS at MIT-AI (Richard M. Stallman) CC: Header-People at MIT-MC Sender: RICK.GUMPERTZ at CMU-10A Message-ID: [CMU-10A] 7 Nov 1977 13:29:05 Rick Gumpertz In-Reply-To: [CMU-10A] 7 Nov 1977 12:43:54 Brian Reid Surely you can search for the field name without the ":" but at the beginning of a line. That will be correct 99% of the time. You can then verify the match using a skip-over-spaces-loop and then check for ":". When you claim you can't efficiently parse something like this in TECO, it only says you aren't the hacker I thought you were. Rick -------  Date: 7 Nov 1977 at 1119-PST Subject: Standards From: Greep at Rand-Unix To: Header-People at Mit-Mc Message-ID: <[Rand-Unix] 7-Nov-77 11:19:13.Greep> Maybe we also need a standard for TECO.  Date: 7 NOV 1977 1129-PST Sender: DCROCKER at USC-ISI Subject: Vote Request: Spacy names and escaping characters From: DCROCKER at USC-ISI To: Header-People at MIT-MC Message-ID: <[USC-ISI] 7-NOV-77 11:29:21.DCROCKER> OK. You are a consultant group, so here's a straight opportunity to consult. Two items have been raised with strong proponents for different solutions. LET'S VOTE. I don't think it is reasonalbe to tally merely according to numbers, since ballot box stuffing is too easy in this setup. However, the vote will be public, so we'll have to be rational in the tally. Please vote by indicating preference AND briefly giving a basis for the preference: 1. Multiple spaces in field names, versus single spacing, only. So far, arguments are that multiple spacing is friendlier, from the human factors standpoint and that single spacing makes parsing easier. 2. Special escape-next-character character, versus only having quoted-strings, with quote-mark doubled. This is a bit fuzzier. Doubling quote-marks involves some potential hair, as detailed by Haverty, and escape-next-character allows to be explicitly indicted, but at the cost of adding yet-another special character to the reserved list. At the end of WEDNESDAY, I will tally and report. (That's two and a half days. I can't allow more time, since the result of the tally may involve changing the spec and we need to pass the revisions past the group again. Dave. -------  Date: 7 NOV 1977 1133-PST From: POSTEL at USC-ISIB Subject: Re: Standards To: Greep at RAND-UNIX, Header-People at MIT-MC cc: POSTEL In response to the message sent 7 Nov 1977 at 1119-PST from Greep at Rand-Unix i love it, enroll me in Teco-People ! --jon. -------  Date: 7 Nov 1977 1444-EST From: Brian Reid at CMU-10A Reply-To: Header-People at MIT-MC Subject: Voting To: DCROCKER at USC-ISI CC: Header-People at MIT-MC Sender: BRIAN.REID at CMU-10A Message-ID: [CMU-10A] 7 Nov 1977 14:44:50 Brian Reid In-Reply-To: <[USC-ISI] 7-NOV-77 11:29:21.DCROCKER> Democracy in action! -------  Date: 7 Nov 1977 1531-EST From: Rick Gumpertz at CMU-10A Subject: Re: Vote Request: Spacy names and escaping characters To: DCROCKER at USC-ISI CC: Header-People at MIT-MC Sender: RICK.GUMPERTZ at CMU-10A Message-ID: [CMU-10A] 7 Nov 1977 15:31:19 Rick Gumpertz In-Reply-To: <[USC-ISI] 7-NOV-77 11:29:21.DCROCKER> For what my vote is worth (I probably will not be implementing a mail parser), here goes: I am in favor of multiple spaces (and even comments) in field names but would not feel upset about not having them. I would like to see the double quoting convention retained, but add some other character as an alternative escape mechanism. The choice of this character, as well as what escapes are provided, should be carefully thought out, however. This may prohibit a good choice in time for the standards book. My personal (and not well thought out) choice would be "\" since it appears on almost all ASCII terminals and is not used for much in normal text. Of course Multics hackers may be either pleased (they already treat \ as special and so will not have to remember another escape character) or displeased (now they will have to quadruple it instead of double it). Rick -------  From: Frankston at MIT-Multics (Robert M. Frankston) Date: 7 November 1977 1433-est Subject: votes Message-ID: [MIT-Multics]1.2.BBBJGwkcMPWgMn To: header-people at MIT-MC 1. I side with the view that white space is white space and that one cannot reasonable tell how much there is so that any amount would be allowed. Before the ":", I'd side with saying that white space is allowed there in the general case so that it should be allowed. This is both a programming generality issue and a human engineering issue. 2. I assume my escape within a quote view is well known. My vote is obviously for the escape character.  From: Frankston at MIT-Multics (Robert M. Frankston) Date: 7 November 1977 1436-est Subject: vote comment Message-ID: [MIT-Multics]1.2.BBBJGwkcZcLDLn To: header-people at MIT-MC On the white space issue, I'd suggest adding a note that field names should be unique so that eliminating all white space before the ":" should not introduce ambiguities. This would simplify very simple parsers.  Date: 7 Nov 1977 1558-EST From: PDL at MIT-DMS (P. David Lebling) Subject: Vote Message-id: <[MIT-DMS].61446> I vote against white space to the left of the colon in a field-name, and for a quoting character ("\" isn't a bad idea). Dave  Date: 7 NOV 1977 1644-EST From: MOON at MIT-MC (David A. Moon) Subject: Voting To: HEADER-PEOPLE at MIT-MC Spaces in field names. Spaces before the field name should not be allowed, because that is ambiguous with folded lines. I think the present BNF may allow them, but that is obviously an unintentional oversight if it is true. Spaces between the field name and the colon look ugly to humans (as well as to programs). Spaces within the field name being printed as multiple are moot since there are presently no field names with spaces in them, but I think no reason has been presented to have them. In any case the present official style is to use hyphen rather than space in field names. Quote-next-character character. Backslash seems like a reasonable choice. I say this even though we are currently using slash and would have to change. I guess it's a good idea to say that quoted letters stand for special characters rather than the letters themselves. It might be a good idea to allow the use of backslash only inside quotes, simplifying life for parsers. Teco. Some header-people may not be aware that ITS Teco (the language Stallman was referring to) is similar only in name to the text editor Teco found on other systems. Teco is a system programming language with semantics similar to Lisp, except there are no lists (only arrays) and extensive string processing has been added. The syntax is considerably cruftier. But the point is that if mail is being processed by a string-processing language, rather than a list-processing language (here I mean PL/I or BCPL more than Lisp), which seems like a reasonable idea anyway, then the lexing idea of the RFC is a more indirect way of implementing it than simply looking for strings. It seems that, for many reasons, things should be kept simple when no user feature is achieved by making it complicated.  Date: 7 NOV 1977 1646-EST From: DLW at MIT-AI (Daniel L. Weinreb) Subject: Votes To: HEADER-PEOPLE at MIT-AI I don't care too much about whitespace in field names, although I don't think they look better in any circumstance I can think of; I wouldn't really care to have my mail look like From :MOON Subject : Improvements to Lisp Machine To :DLW or anything like that. What I am trying to say is that people seem to be taking the view that anything that makes the standard less restrictive will also serve to make headers look more pleasant. This is usually the case, but not here. I would definitely like a special quoting character. After seeing super-hairy quoting issues in Multics many times, I would really like to get away from them; in ITS we usually use quoting characters and it hardly ever causes pain. -- Dan P.S. Sorry if this letter gets an internal-ITS header, I'm trying something in the mailer and I may have screwed up.  Date: 7 Nov 1977 1714-EST Sender: BRIAN.REID at CMU-10A Subject: Semantics of :INCLUDE: From: BRIAN REID(C410BR10) at CMU-10A To: Header-People at MIT-MC - - - - I have a subtle question about distribution-list semantics. If I put out a field that says TO: :INCLUDE:"Pathname"@CMU-10A then I am asserting that Pathname represents a valid FTP path that can be used to retrieve a file containing addresses. If I put out a field that says TO: "Pathname"@CMU-10A then I am asserting that Pathname is a valid mail-recipient code to be handled by CMU-10A, and that mail to Pathname at CMU-10A will somehow go to a useful place. What do I say if I want to make both assertions: that both (1) Pathname is a valid FTP path usable to retrieve a file, and (2) Pathname is also a valid mail recipient name. One possibility that comes to mind is the amazingly baroque construction: TO: <"Pathname"@CMU-10A, :INCLUDE:"Pathname"@CMU-10A> Anybody got any ideas?? Brian -------  Date: 7 Nov 1977 1723-EST From: Brian Reid at CMU-10A Subject: Vote To: Header-People at MIT-MC Sender: BRIAN.REID at CMU-10A Message-ID: [CMU-10A] 7 Nov 1977 17:23:38 Brian Reid (1) Blanks. I feel that the rule of visual fidelity should be followed: that all ways of representation that will look the same on my screen should be equivalent. If I squint carefully, I can tell the difference between 1 blank and 2 blanks, but it's a subtle difference. I think that anywhere in the system where one blank is allowed, multiple blanks should be allowed. A reasonable action for header fields would be to parse them like FORTRAN variables: that REPLY TO and REPLYTO would be equivalent. (2) Quotation. I really don't care at all. I think that the surrounding quotes look better to the eye than do quote- next-character schemes. Brian -------  Date: 7 Nov 1977 1714-EST From: Philip Karlton at CMU-10A Subject: Re: Vote Request: Spacy names and escaping characters To: Header-People at MIT-MC Sender: PHILIP.KARLTON at CMU-10A Message-ID: [CMU-10A] 7 Nov 1977 17:14:47 Philip Karlton In-Reply-To: <[USC-ISI] 7-NOV-77 11:29:21.DCROCKER> My vote: 1) I don't care one way or another. I really do not see a need to have spaces within the field name or between the field name and the ":", but it does not bother me if they are there. 2) I vote for the quote character. I assume that only the ultimate mail reading program is allowed to strip the quoting character and that intermediate FTP servers and mail forwarders will not be messing with the headers. PK -------  Date: 7 NOV 1977 1811-EST From: RMS at MIT-AI (Richard M. Stallman) To: HEADER-PEOPLE at MIT-AI Recently I asked that the standard be changed in a way that would make it easier for my TECO program, RMAIL, to parse. After all, when I asked who actually wanted the feature that I would remove, nobody said that HE actually wanted it. Indeed, IF the standard were approved in its current form, mail might be legitimately sent which my program, as now written, could not parse, and that would be "my problem". And I could modify it to make it more complicated and slower, as suggested, and the degradation would also be "my problem". I would have to choose between the two problems. I can already tell what my choice would be: the more efficient solution that might lose on mail that would probably never be sent. However, the standard is not finalized, and if it is changed, I might escape that dilemma. Isn't it reasonable for me to ask for that? of course, the decision has to be based on other people's interests as well as mine. I wasn't denying other people's opinion's importance merely by asserting that of my own. I have also been criticized by choosing TECO to write my program in. Indeed, if it were written in machine language there would be no such parsing problem. There would also be no point in writing it. Who would use it, when he could instead use RMAIL and have his favorite editor available for composing replies? My choice was based on reasons, which involve things more important than this parsing problem, and are in no way invalidated by it.  Date: 7 NOV 1977 1817-EST From: RMS at MIT-AI (Richard M. Stallman) To: HEADER-PEOPLE at MIT-AI I observe that most opinions in favor allowing spaces before colons and multiple spaces in field names is based on "defending the other man's right to use them". Such a feeling is noble, but the "other man" has yet to speak up who actually wants to use them. My conjecture is that there is none. If you do exist, though, by all means speak up.  Date: 7 NOV 1977 1618-PST Sender: DCROCKER at USC-ISI Subject: spacing From: DCROCKER at USC-ISI To: header-people at MIT-MC Message-ID: <[USC-ISI] 7-NOV-77 16:18:02.DCROCKER> One reason that we do not have a history of field-names with multiple spaces (or even multiple words) is that most mail-reading programs would hiccup if they had to process them. I therefore will offer a few examples of field names which might reasonably be constructed. In fact, there are real-world situations in which these formats ARE used: To : Primary recipients From : Dave Crocker Subject : Examples Keywords (management) : foo bar blat Keywords (technical) : grelp grelch Filing (management) : Room 305, Drawer 2, Hassles Filing (technical) : Room 1705, Drawer 10, Syntax THis is a fairly unusual organization, since the technical staff is higher in the building thatn management. I should note that I am not offering these examples whimsically. They constitute entirely reasonable choices that an organiztion might make and I think it entirely UNreasonable for us to preempt that decision. Dave. -------  Date: 7 NOV 1977 1704-PST To: Header-People at MIT-MC From: Hathaway at AMES-67 Subject: Dave's examples of field-names with spaces Dave's examples of field-names with spaces in them (so that the colons line up nicely down the page) would have been a bit more effective had the aligning not been done with tabs, so the colons would have lined up on ANYBODY's system, not just those that happen to be stuck with the TENEX tab settings ... ------  Date: 7 Nov 1977 2134-EST From: Rick Gumpertz at CMU-10A Subject: Balnks and quotes To: Header-People@MIT-MC Sender: RICK.GUMPERTZ at CMU-10A Message-ID: [CMU-10A] 7 Nov 1977 21:34:52 Rick Gumpertz I feel that blanks should be allowed before the colon simply because in all (I think) other contexts, blank is allowed before colons. Suppose your favorite compiler insisted you could have white space after a "+" but not before it! I agree with the suggestion that field-names be FORTRAN like -- i.e. white space would be totally ignored within them. (Maybe even ignore "-", making "Reply-to" equivalent to "Reply to"?) This would allow RMS to preprocess all the blanks out before parsing. Of course to preserve some semblence of alignment, if there was any, he could move the blanks to after the ":", rather than delete them. I assumed we were only talking about recogizing the quoting character INSIDE quoted strings. Is someone proposing otherwise? Rick -------  Date: 7 NOV 1977 2234-EST From: KLH at MIT-MC (Ken Harrenstien) Subject: Spaces in fieldnames and quote/escape char To: HEADER-PEOPLE at MIT-MC [1] Spaces in field names - NO I vote against them. This has little to do with RMAIL and RMS need not worry about parsing such things even if spaces are retained, because the COMSAT mailer for AIMLMC will be able to reformat the header before it is written into one's mail file. This re-formatting is why I object to spaces at all. Why are they there? So that some people (still unnamed, Dcrocker to the contrary) can get their mail looking like that. Now, the sort of people who are likely to send such headers to each other are precisely the sort of people who would be using hairy mail programs, meaning that they would in fact almost NEVER see their mail the way it was sent! And if they so chose, they can just tell this selfsame hairy program to print out their messages with colons appropriately justified. Moreover, not allowing arbitrary spaces makes the job easier for these programs which do reformat things, and keeps the header more compact for people who can't reformat them, lets simple mail filters stay SIMPLE, etc... In Dcrocker's example of "Keywords (management) :", I don't see why the comment can't be to the right of the colon, and in any case you are supposed to be discouraged from the use of multiple occurrences of such fields, which kind of invalidates the distinctions you make. I don't by the way mind having single spaces in a field-name if they are part of its canonical representation. I do have one recommendation however: Field names must be unique within their first N letters. N should be something like 15 or 16; the idea is to allow programs (especially simple ones) to allocate a fixed size buffer for field name matching which will always be sufficient. 16 characters seems entirely adequate, but 32 is still reasonable from a storage viewpoint. Spaces in field-names have nothing to do with spaces in other parts of the mail header. Some things that have been said seem to confuse this distinction. [2] Escape Character - YES A good idea. Allowing it only within quoted-strings is probably best. Quoting in general is something that needs more clarification as to what is quoted where; it is not just the "mail reading" program that they are aimed at, since the FTP server and the mail delivery program (COMSAT) are separate processes from AIMLMC's "mail reader" RMAIL, and funny things can happen - for example, if you give KLH@MC to the AI FTP server, it will mail the message to KLH at MC, not "klh@mc" at AI. Talk about laundering. ---- Aside to Dave C... could you make sure that my last name in the paper is spelled exactly as it is in the header of this message. I know, I know... --Ken  Date: 7 NOV 1977 2301-EST From: RMS at MIT-AI (Richard M. Stallman) To: HEADER-PEOPLE at MIT-AI Please don't claim that fortran-like syntax is going to be any good for me! Whatever merits it may have, that is not one of them. I would prefer the way the draft reads now; at least that way nobody will probably ever do the things I won't handle.  Date: 7 NOV 1977 2354-EST From: MOON at MIT-MC (David A. Moon) Subject: RICK.GUMPERTZ@CMU-10A (Balnks and quotes) To: HEADER-PEOPLE at MIT-MC Oh, God! I didn't used to think that MRC had a point in his flaming about simple headers, but now people are proposing that one's mail software has to be comparable to a compiler. I guess I'll go pound my head against a wall for a while, it's more useful.  From: Frankston at MIT-Multics (Robert M. Frankston) Date: 7 November 1977 2336-est Subject: quoting versus escaping Message-ID: [MIT-Multics]1.2.BBBJGwlZjDQgdz To: header-people at MIT-MC I apologize for confusion I may have introduced in terminology. We have three cases for quoting: 1. The pl1 method of using " around strings and doubling them inside strings. 2. The quote-character method of not having a string quoting character, but instead quoting individual characters as needed. This is done in Lisp (at least MACLISP) with the "/" character. I.e. This/ is/ a/ single/ token. 3. The escape character. This is used within strings to indicate a special interpretation. For example (to persist with my ~ since I don't like typing \ four times), ~q for quote and ~n for newline. This is the convention I favor. It really means that " is not used for quoting as such, but simply an indicator that the lex can ignore everything until the next ". Only programs that actually process a given field need be concerned about further interpretations. I think that this is favored over # for generality (~n for example) and simplicity (~q can be ignored almost everywhere). I think is also produces more readable text than much single character quoting. (even Lisp has adopted | as a token quoting character in the sense that " is intended).  Date: 8 NOV 1977 1404-PST From: POSTEL at USC-ISIB Subject: Votes on Spacy Names & Escaping Characters To: Header-People at MIT-MC 1. On multiple spaces in field names: my feeling is that field names ought to be consistent and arbritrary spacing tends to eliminate that consistency. i don't feel strongly about this either way. If my mail reading program offered the option of reducing multiple spaces to one, and eliminating a space before a colon i would use that option. i can feel some sympathy for the difficult to parse argument, but i really don't think that should be a major factor. that kind of argument is more appropriate as a tie-breaker for use when two equally powerful, flexible, etc. schemes are under consideration. It seems to me that the the multiple space provision is more flexible so i favor allowing it. 2. escape vs quote: i favor the escape character mechanism here, it seems to have slightly more power and be somewhat simpler to implement. --jon. -------  Date: 8 Nov 1977 2122-EST From: RICART at DEC-MARLBORO Subject: Vote To: DCrocker at USC-ISI cc: Header-People at MIT-MC 1. On spaces in field names: (a) Where one space is allowed, multiple spaces should be allowed (pardon, multiple linear-white-space-chars) (b) The examples of spaces before colons all look like bad English, so I see no reason to keep them for "readability". I don't therefore see the need for allowing linear-white-space before colons (i.e. after the last atom) unless it produces something that is easier to describe, implement, and/or parse. 2. On escape character in quoted strings versus PL/I quote doubling, I vote for the escape character. Perhaps it could be a control-character so as not to take up a graphic. 3. On FORTRAN-style header names (i.e. please ignore all white-space), ugghhh...I'd much rather parse multiple atoms. . . . . Glenn (NIH) -------  Date: 9 Nov 1977 1144-EST Sender: DIANA.BAJZEK at CMU-10B Subject: my vote From: DIANA BAJZEK(S300DB33) at CMU-10B To: header-people at MIT-MC - - - - As the maintainer of CMU's mail program I'v learned that you can never please everyone, but that if you ever make a decision which disallows something.....you are guaranteed that you will soon hear from people who cannot live without the feature you have disallowed. I vote for allowing white spaces in the field name. -------  Date: 9 NOV 1977 0953-PST To: Header-People at MIT-MC From: Hathaway at AMES-67 Subject: My votes on spaciness and quoting Spacy field names: Isn't the whole idea behind standard field names so that both humans and programs can quickly recognize what header field is present? Therefore it seems to me that what we really want is ONE standard way to write each field name. After all, we don't allow "TOPIC" and "THOUGHT FOR THE DAY" and "CONCEPT BEING DISCUSSED" as synonyms for "SUBJECT", so why allow "SUB JECT" or "S U B J E C T" (which are really no sillier than "IN REPLY TO")? Keywords (tokens) should really have one and only one way of being written. Thus I would vote for exactly one space (or even hyphen) in places where spaces are desirable ("MESSAGE ID" or "IN REPLY TO"). In fact, aren't these fields normally going to be written by mail sending programs rather than humans? So why have several forms? Now as far as whether the terminating colon is really part of the keyword or not, I would vote that it is, and must be immediately adjacent to the key- word. Thus the keyword is "IN REPLY TO:" and any other text is some- thing else. Quoting: Here I vote for the "quote next character" scheme, as its problems seem to be more obvious than those associated with quote doubling, which would probably mean fewer incompatibilities due to implementation bugs. ------  Date: 10 NOV 1977 1850-EST From: JZS at CCA Subject: RFC #733 To: DCrocker at USC-ISI cc: Header-People at MIT-MC Hi -- This latest version of the Standard looks cleaner than the previous, and reads very well. Herewith some typos, etc. p iii Ken's name p1,p24 "supercedes" should be "supersedes" p8 "qtext" definition "exceping" should be "excepting" p10 pp 'e' "specials" should be "special" p17 last pp line -3 "happended" should be "happened" p20 pp B.1. last line "message should receive new ..." could better (?) read "message should each receive a new ..." I'd like to mention a couple of other matters upon which you might care to comment -- 1. MARS-Filer currently defaults archiver-name to from-field-name unless otherwise specified by ARCHIVER: field. This seems to conform to the intended usage of the FROM/SENDER fields, no? The archiver of a message is an 'originator' of sorts but I see no way to augment that category of field name in the specs. I wonder if there's much interest in explicitly mentioning archiver name (or message disposal in general) in the Standard. 2. I'm currently working on the notion of "limited access lists" - i.e., specifying on a per-message basis who is entitled to retrieve it (from the Datacomputer). My inclination is, for the default case, to include all recipients as well as all originator-fields names. This would amount to ignoring the recommended usage of the various fields, sorry to say -- but the impact is, I think, negligible. "RETRIEVERS:" or "ACCESS-LIST:" could certainly be a user-defined optional-field; but might there be some interest in explicit mention of such a feature? S'all for now, Joanne -------  Date: 10 NOV 1977 2054-EST From: KLH at MIT-MC (Ken Harrenstien) Subject: Last Words (he said wistfully) To: HEADER-PEOPLE at MIT-MC DCrocker wanted comments by the 10th, so after the necessary grovelling over 733 I have come up with some. It is getting more and more difficult; the more I study it the less I actually see, because I've seen it so many times before. My eyes just glaze up and skip to the next page... In no particular order: [1] In the list of I strongly suggest adding "[" and "]" since we have been talking about using them for bracketed quoting, and even if we can't afford the time to get everything straight for publication, we can certainly ensure that nobody stats using them for something funny in the interim. I would even recommend that a short statement be added explaining why "[" and "]" are there - because a future extension is planned which will use these for nested bracketed quoting. [2] in definition of , exceping => excepting. [3] Page 10, II.B.e "in an host-" => "in a host-" [4] Previously the definition of a group allowed a null group. This has been fixed, but now it allows a null group name! What is the meaning of that? Or is it a bug? I'm pretty sure it's a bug because otherwise you could have "To: ::Postal:blurb;" and the "::" would be seen as a null "data type", with "Postal" the name of a group composed of "blurb"! [5] def of , "must must" => "must". A A little little odd odd.. [6] still allows a day-of-week. Looking over the past Header-people messages, I find 3 people favor putting day-of-week into a comment, with none opposed. If anyone still wants an argument explaining why we think it belongs in a comment and not a definition, I will gladly pull out these past messages and re-send them. I notice that HARV-10, the only place that I know of which puts day-of-week in dates, is putting them in parentheses! (win). So, why not just "date-time = date time" as the definition? Include a little note to the effect that day-of-week may reasonably accompany it as a comment... [7] definition of could be improved with respect to the comments by stating that "local differential" is "local differential from GMT", and restating the military zones as something like "A:-1, B:-2,... M:-12, N:+1,... Y:+12" which makes it clearer that a sequence is involved. [8] IV.A.2.a page 18, how about restating the last sentence smething like "If this is not done, the sender field MUST be present". The way it sounds now, the first impression is that it must ALWAYS be present, and a minor convolution is necessary to backup. [9] IV.A.2.b Damn, this part has always been and still is confusing. "The phrase (user)" is still throwing me for a loop. How about this paraphrase of the last paragraph: The in the Sender is intended to correspond uniquely to some single human user, rather than being just any normally allowable address. It should refer to the PERSON responsible for sending the message. For example, if two or more people share the same account or mailbox, using just the mailbox name for the is not enough because it won't show which of them actually sent the message. Related to this is the problem of machine-sent mail. On all ITS systems it is possible for the mailer demons to originate messages, and it is possible for any program to easily send mail whether under human spervision or not. So I suggest that one further point be made about originator fields, to the effect that "PERSON" may in some circumstances actually be a program, and that these fields should then serve to make it clear what program sent the message. Probably this need not refer to the exact instantiation of a process as in "Job 10 loaded from DSK:.MAIL.COMSAT LAUNCH at 13:13:13" but rather just the program's common name, "COMSAT". Any addresses furnished must of course be acceptable to the FTP server etc., and presumably would be vectored to the program's maintainers, or similar people, if a reply were actually made. (or "Reply-To" could be used!) [10] IV.D about dates and tims isn't much clearer about military time zones. Which reminds me, why are military zones in there at all? If they HAVE to be there, I would like ths paragraph to say that they are not recommended, except for cases in which no equivalent ANSI zone name exists. Question, instead of EST one can use "E" for offset of -5, but what happens when daylight savings time starts; does this have to be changed to "D" for offset of -4, or does the military pay attention to this? (I am reminded of Brian Reid's note that "time zones are a headache and a half".) [11] Alfred E. Newman. Is this spelling deliberate? I can't decide if it's a contrived pun or a parity error for "Neuman" in smeone's memory. Sigh. [12] There is a subtle catch in giving spaces to a FTP server; one is supposed to pass "exactly ONE" space for all these cases: "foo(b)ar", "foo (b)ar", and "foo (b) ar". In other words you can't just substitute a space for a comment, because that will give you too many spaces,etc. In actual fact I think that this should be "AT LEAST one" space; it would be pretty stupid of a FTP implementor to assume otherwise. If exactly one space is important, the name should be quoted. Does anyone disagree with making it say "at least" instead of "exactly"? [13] Page 26, "Other Host" => "Other-Host". [14] re example on page 26: It isn't clear at first that "Special (action)" is intended to be a fieldname distinct from "Special"; it looks at first as if the rule prohibiting comments from fieldnames is being violated. This threw me off in my vote about spaces in fieldnames, because I didn't realize Dcrocker's example of "Keywords (management):" wasn't actually using a comment. I finally figured it out, but another sentence or two might help explain. There's no reason, in any case, why one can't define "Special" and others as taking their first atom as a type indicator, so that all the whitespace hair is in the field, not the fieldname: "Special: Action! This..." [15] In the same example, the "Important folk" group is not terminated by a ";". Also, something like :postal::include: is meaningless in my opinion, as is :include::postal:. More later. [16] The stuff about message ID's has not been improved since I last complained about it. What I would like to see is a statement that the angle-brackets should be considered part of the ID, and hence get carried around with it everywhere; it is not necessary then to keep saying that "if id's are used they must be surrounded with...". Furthermore it should state that everything between and including these angle brackets is to be treated as a literal string; not as a quoted string, because that connotes too many wrong things, but as a piece of text which is not to be modified in any way. Also, frankly, it is much more difficult to parse them than it should be, because you have to watch out for quoted closing angle-brackets, i.e. one could have 56>78" at AI>. Due to the necessity for preserving the string exactly, it is rather useless to run the mailbox-recognizer lexical analyzer over it, because you will just have to kludge up something to get around the tokens. I really would recommend making the message-ID a completely different definition, jus as quoted-strings and comments have their own definitions; each is a special kind of string. I seriously think this particular field has a lot of potential for being fouled up if the current definition is retained. Phil's comments also apply. [17] I am not happy with the way "extended data types" like :INCLUDE: have "address" following them in the definition. I think this is a big mistake. It lets you do weird things like ":include::postal:foobar@host" which is meaningless; you can't "include" an address of ":postal:foobar@host" because it's not a filename! (it mght be, but that clearly is not the intent, whatever it is!) Also, you don't want to imply that all the addresses in the file "foobar@host" are of type Postal, because such information should accompany each name in the file, and.. and... goddammit, read Page 16, IV.A, 6th paragraph from top of page, and tell me what to make of that, combined with this type of construction! My recommendation: :INCLUDE: should be followed by a , and :POSTAL: should be followed by either a phrase or quoted-string. Now read the 5th paragraph on the same page, saying "Elements of the address list part are alternates...". Sigh, moan, groan. WHAT ADDRESS LIST? There is only one address allowed, not a list, in the definition of :include:. If this refers to the scheme of having a [phrase] "<" 1#address ">" stuck in there, then just possibly the paragraph is talking about a list between the "<>"s. But now I am even more enraged. Why this concept of "alternates" and why does it appear in this curious fashion?? Someone, someplace, has some conception of how :INCLUDE: is supposed to win, but none of it is getting through and I am stumbling around in the dark trying to figure out which end is which of this remarkable animal I am supposed to implement. I don't like these "alternates". If some general scheme for them can be thought up, which will apply to ANY address, fine. That might even be useful, if complicated. But otherwise I don't understand what the point is of going to all this trouble. [18] I think it might be useful to have a little section of the appendix, much like Appendix B, which would collect together all of the issues involved in passing strings to the FTP server. In particular it would emphasize how to remove quotes and suchlike. Most of this is already scattered through the document and just needs to be collected. [19] Bracketted names (such as [type [nested stuff]]) seem to avoid both the problems of "what comes after the specification and how do I ignore it" and binding the type to the recipient text simply, as well as avoiding a lot of the quote hassle because the delmiters which serve to begin/end quoting are always included in what one gives to a FTP server; this is just another plug for including a statement that an extension of this sort is being developed. [20] This is not really a comment on 733 except insofar as it doesn't include something I would like to see: a sketch of how the changeover is to be accomplished. As I mentioned in my last large comment message, I am mostly worried about two things: (1) easy filtering of headers, and (2) non-catastrophic changeover to new standard. Not a word has been said about how the committee expects the latter to happen. Some of us have proposed ideas, but no acknowledgements resulted. My feeling is that the reluctance of Clements to do any work on the Tenex FTP programs (which has biased Vittal and Henderson, I think) should not prevent the consideration of minor changes to FTP servers. There are plenty of Tenex hackers who would be happy to mung the server, if what the Hermes people need is not too extensive. Moreover, establishing a new socket for these tweaked servers (if tweakers want to be very careful) is also easy to do. Sigh. -------- A couple other things about the vote issues. I think Ted Haines mentioned (in a message to me about another subject) that "\" couldn't be represented on his terminals. But looking thru a TIP manual for 2741 equivalences, I find that almost everything has representation problems; it must be very frustrating. I would not mind "~" myself, but it doesn't even exist for some TTY's. How about ^Q (control-Q) or even ESC? If thse ae allowed in the text anyway, then they should be considered; every site will have SOME way of representing these, and there is no standard representation to fight about, and they are rarely used. Here's an actual ^Q or two:  and here's a couple ESC's:  Or something similar. Ricart has also suggested using a control char. As for spaces, I think Jon Postel would make a great politician... ----- Thats all folks... --Ken  Date: 10 Nov 1977 at 1800-PST Subject: THE VOTING RESULTS From: Dcrocker at Rand-Unix To: Header-People at Mit-Mc Message-ID: <[Rand-Unix]10-Nov-77 18:00:53.Dcrocker> Turned out to be rather interesting. The following numbers do not include any voting by members of the committee because it turned out they weren't necessary (i.e., wouldn't have had any effect)! Some of the voting was not clearly in favor or against the defined issues and so I chose to allocate the votes in a semi- rational and personally-biased way. In particular, anyone who did not explicity vote for or against multiple spaces (some said they "didn't feel strongly", for example) got counted as voting FOR the multiple spaces. Take this as an indication of how strongly the committee (me, in particular) feels about allowing them... For multiple spaces: 9 Against 6 I had expected MIT to dominate the nays, but they didn't. The idea to "ignore" spaces, as per FORTRAN, didn't spark very much interest, tho I thought it was a clever suggestion. For doubling quotation marks: 1 Against 12 Seems pretty definitive. Some of the comments continued to reflect poor understanding of the spec in its current form. In particular: spaces are not allowed at the BEGINNING of a field name, since this obviously would be ambiguous with respect to continuation. This point is mentioned, in a variety of ways, throughout the document. So, we will add another special (backslash got a sizeable number of votes). I expect it will operate in ctext and qtext only (i.e., quoted-strings and comments). Dave.  Date: 10 NOV 1977 2137-EST From: MOON at MIT-MC (David A. Moon) Subject: 733 To: HEADER-PEOPLE at MIT-MC I agree with Ken's comments, especially points 1, 12, 16, 17, 18, 19. One thing I think needs to be said is that I still find the originator-fields extremely confusing (see KLH's point 9 and section IV.A.2.b of the RFC). The syntax says that 'Sender:' is followed by 'mailbox', but the semantics says that the sender is specifically not a mailbox, but a person. Is the sender field to be ignored by programs, unless it is of the form 'Sender: Person ', which is the second of two alternative forms for 'mailbox' given by the syntax? But this form does not appear in any of the examples. In the next section it says the "Sender host-phrase" (is this the same as the contents of the sender field, or does it mean the contents only if it is a host-phrase [the first of two alternatives]?) should NEVER go in a reply address list. Hmm, maybe just the BNF is wrong, and it's supposed to be 'sender= "Sender:" host-phrase'? A related problem is that the syntax for 'address' is confusing, if not wrong. It seems strange that 'quoted-string' is allowed for arbitrary, non-Arpanet addresses, but not 'phrase'. For a long time this lead me to think that quoted-strings were stuff not to be given to FTP servers, until people started discussing how to give them to FTP servers. In fact quoted strings appear (in the rest of the syntax) to be as good as words, the quotes being used simply to protect special characters. The separate definition of 'mailbox', which is not a form of 'address', is also a source of confusion. This whole thing would be a lot clearer if it did not use the syntax to express things like "addresses not containing a host-indicator are arbitrary text, not to be sent to an FTP server" and "the From field must contain a machine mailbox if the Sender field is not present", but relegated those to the semantics section. Note that the second quoted string above is contained in the present syntax but inconsistent with the present semantics; it looks like you are halfway through changing your mind about the difference between "From" and "Sender". If you don't clear this up before publication, it seems unlikely that all the implementors will interpret it consistently. For reference: --- originator-fields = ( "From" ":" mailbox ; Single author ["Reply-To" ":" #address] ) / ( "From" ":" 1#address ; Multiple authors & "Sender" ":" mailbox ; may have non-mach- ["Reply-To" ":" #address] ); ine addresses address = host-phrase ; Machine mailbox / ( [phrase] "<" 1#address ">") ; Individual / ( [phrase] ":" 1#address ";") ; Group / quoted-string ; Arbitrary text / (":" ( "Include" ; File, w/ addr list / "Postal" ; (U.S.) Postal addr / atom ) ; Extended data type ":" address) mailbox = host-phrase / (phrase mach-id) mach-id = "<" host-phrase ">" ; Contents must must ; never be modified! ---  Date: 10 NOV 1977 2220-EST From: MOON at MIT-MC (David A. Moon) Subject: <[Rand-Unix]10-Nov-77 18:00:53.Dcrocker> (THE VOTING RESULTS) To: HEADER-PEOPLE at MIT-MC I guess last week's message about ballot-box stuffing being easy in this system was true. Crocker's message doesn't mention anything about spaces between the field name and the colon, which is the real issue. Whether multiple spaces are equivalent to a single space is not too relevant since no interesting fields (in fact no fields at all in the present RFC) have single spaces in their names.  Date: 11 Nov 1977 0036-EST From: Philip Karlton at CMU-10A Subject: Re: Last Words (he said wistfully) To: Header-People at MIT-MC Sender: PHILIP.KARLTON at CMU-10A Message-ID: [CMU-10A] 11 Nov 1977 00:36:12 Philip Karlton In-Reply-To: Ken Harrenstien's message of November 10, 1977 I basically agree with Ken's comments. Some thinking should be done before a use for control characters gets defined so that in some situations they would have to be in messages. There are terminals that react strangely when they recieve some control characters and not all operating systems force "SOME way of representing these". It would be nice if a non-catastrophic transition from the old to the new headers could be accomplished and current mail reading programs (as well as those people stuck with PIP and friends) need not be treating the control characters (in general) as special. PK -------  From: Frankston at MIT-Multics (Robert M. Frankston) Date: 11 November 1977 0201-est Subject: strange little beasties Message-ID: [MIT-Multics]1.2.BBBJGxBMJCpfPf To: header-people at MIT-MC Please don't put ASCII control characters in graphc strings. They are intended to do wierd and wonderful things. For example control-q tyically turns on one's paper tape readers. ESC is used for all sorts of horrendous and random things. Just because the model 33 teletype happend to not print them ha lead to their continued misuse though the years. I agree that our character set is not big enough, but delving into the control area is not the appropriate way to extend it. (Well there are things like shift-in and shift-out. In fact, my computer uses nine bits for each character. The obvous thing that everyone should do is add 512 to the $a By the way, where did your escape and control-q disappear to, I never saw them in my copy of the letter.  Date: 11 NOV 1977 0307-EST From: KLH at MIT-AI (Ken Harrenstien) To: Frankston at MIT-MULTICS CC: Header-people at MIT-MC "Just because the model 33 teletype happend to not print them ha lead to their continued misuse though the years." Tilde ("~") isn't printed on a model 33 either. I don't really get your point. "In fact, my computer uses nine bits for each character. The obvous thing that everyone should do is add 512 to the $a" Huh? It may be obvious to you, but not to me. $a? Typo? "By the way, where did your escape and control-q disappear to, I never saw them in my copy of the letter." Aha! It was a test to see what you'd get. The fact you got nothing is interesting. They are certainly present in my mail file... I'm really surprised that Multics doesn't want to represent them in some fashion. ITS has used these control characters (and others) for years with no problems, so I am not really used to the idea that systems may exist (as Phil implies) which really can't, for example, print dollar-sign in place of ESC when printing such a thing is requested. Certainly an "image" output of ESC or other controls will cause problems. It would be interesting to hear from other people about this. --Ken  From: Frankston at MIT-Multics (Robert M. Frankston) Date: 11 November 1977 0308-est Subject: sarcasm and but we've been doing it for years Message-ID: [MIT-Multics]1.2.BBBJGxBQwmMqWh To: header-people at MIT-MC cc: klh at MIT-AI 1. I intended to be sarcastic about the 9-bits. I was just reacting to the common problem of a solution that is local to a given system being suggested for the network. 2. The control characters are just such a solution. They have defined meanings in ASCII. To expect that all systems leave them untouched is a matter of local chauvinism.If the control-q did arrive in my mailbox (or the escape) they both would have been printed with suitable conventions in octal (or in my particular processes as character preceded by caret backspace vertical-bar (i.e. up-arrow)). Currently Multics is making limited use of ESCapes in files intended for theline printer to control carriage operation. I expect the IBM/EBCDIC world to be much less amenable to these strange creatures showing up. I realize that many systems do make extensive use of control characters and that it has worked for them. But within the confines of any system, things will continue to work. In getting outside the system that one runs into problems. Another example is the issue of tabs (control-i if you insist). Sure, they have always meant a multiple of eight spaces. Ever since the beginning of time. Well, that is again true, but within a given set of systems. Forgive, I am rambling a bit, but this is an example of the "Tenex syndrome" (yes, I know you are on ITS and use other systems so perhaps we should call it the PDP-10 syndrome) wherein experience on such systems leads to proposals that do not take into account issues faced on other kinds of systems. Since 10's dominate the net, however, it is easy to imagine that they re the whole world. Enough said?  Date: 11 NOV 1977 0337-EST From: KLH at MIT-AI (Ken Harrenstien) Subject: Control char chauvinism To: Frankston at MIT-MULTICS CC: Header-people at MIT-MC It is rare that any one person knows enough about all other systems to propose immediately winning things; so, we just have to iterate and collect information. I certainly like the amount of input from non-PDP10 people. I don't think I managed to set down the main angle I was thinking about (unconsciously) when I proposed ^Q or something similar. This is that I believe "~" (tilde) is not, in general, accurately represented on older ASCII terminals; nor is it present on EBCDIC ones (am I right?) whereas the concept of "control char" has an extremely standard representation for ASCII terminals as uparrow followed by an uppercase letter, and I think on 2741's the TIP prints " (doublequote) followed by the lowercase letter. If any people have ideas for such an escape/quote char, please bring them out. One last thought: perhaps the standard should be written with provision for a quote/escape char, without actually specifying what it is -- a note would say that the exact definition is to be settled in an extension. This would give the time to make a careful choice, if time is really needed that badly. Oh well. --Ken  From: Frankston at MIT-Multics (Robert M. Frankston) Date: 11 November 1977 0341-est Subject: control characters Message-ID: [MIT-Multics]1.2.BBBJGxBXlQpqQk to: header-people at mit-mc If we are designing a general purpose mail system I vote against control characters for a number of reasons including: 1. I suspect that it will be harder to explain to naive users than the choice of a graphic escape. 2. Even though 2741's on TIPs can type them, not all systems provide a mechanism. In particular on 360's it is probably not a simple process. The "~" was meant to be an unusal character, though admittedly would give grief to a model 33. Maybe it will have to be \, the most unused character on a 33, though tying \\ requires four keystrokes for me.  Date: 11 Nov 1977 0329-EST From: Philip Karlton at CMU-10A Subject: Re: Control characters To: KLH at MIT-AI (Ken Harrenstien) CC: Header-People at MIT-MC Sender: PHILIP.KARLTON at CMU-10A Message-ID: [CMU-10A] 11 Nov 1977 03:29:00 Philip Karlton In-Reply-To: Ken Harrenstien's message of November 11, 1977 When I got the ^Q, my MiniBee4 sent my entire screen back to CPU as if I had typed it in. If the monitor always mapped characters (e.g. escape to $) then it would be hard for programs to do cursor control. It is up to each program to do the mapping it wants. This loses for "dumb" programs like RDMAIL here at CMU. [[I am really not interested in hearing a discussion of how the monitor should be doing the cursor control since it handles multiple terminal types. I know that my monitor does not do this and it probably never will. Programs that do cursor control have to each have the code to handle the different types.]] PK -------  Date: 11 Nov 1977 1035-EST Sender: BRIAN.REID at CMU-10A Subject: Control characters From: BRIAN REID(C410BR10) at CMU-10A To: Header-People at MIT-MC - - - - A number of years back some short-sighted person at Stanford went and assigned graphics (the so-called Stanford character set) to most of the ASCII control characters. For historical reasons, CMU is saddled with them, too. It has caused absolutely no end of grief, even though nobody anticipated any of it at the time. Using a random control character for the escape character would be dumb. If the ESCAPE (ALTmode) character in ASCII hadn't been pre-empted by DEC systems to mean 47 different things, it would be the correct choice; its purpose in ASCII is, strangely enough, as an escape character. Given that we can't use ESC for an escape character, I don't think that we should randomly misuse some other ASCII control character to mean ESCape. If we worry about TTY33 compatibility, we also have to forget about "{", "}", "\", "|", "`", and "~", none of which it can print. But do we have to worry about TTY33's? Isn't it the case that this escape character could/should be put in by the mail program and not by the user? Brian -------  Date: 11 Nov 1977 1113-EST Sender: RICK.GUMPERTZ at CMU-10A Subject: The escape character From: RICK GUMPERTZ(N810RG02) at CMU-10A To: Header-People at MIT-MC - - - - I STRONGLY object to the escape character being a "control" character! Rick -------  Date: 11 Nov 1977 0847-PST From: MRC at SU-AI (Mark Crispin) Subject: "control" characters To: Header-People at MIT-MC First off, model 33 TTY's can print "\". Somebody, I think Brian, claimed they couldn't. Second, I disagree with the Stanford character set being short-sighted. I think it is a win. In its proper implementation (see my SUPDUP RFC for the way the ITS systems at MIT do it, which is a but not the only "proper way") you have a 7-bit display character set, all of which are used; a 9-bit keyboard character set (the display character set plus the "control" and "meta" bucky bits) and MIT's 12-bit extension of the 9-bit set (this last allows one to sense the state of the "top" bit so you can tell the difference between, for example, backspace and lambda, form feed and plus-minus... SAIL glosses over this difference). All the formatting things you can ever want are available, but they don't take up valuable printing character positions. FINALLY, I realize that the world is not ITS and SAIL. And I feel instead of local system chauvinism we should endeavor not to screw anybody. I feel that if a proposed "feature" does screw somebody it should be flushed for that reason (which is completely consistent with my position irt short headers). Hence I feel that "ASCII control characters" should not be used for this. Not enough places implement the Stanford character set and too many places gleefully pass these characters in image mode (or ignore them totally) to terminals which use them as random formatting characters. There are times I could shoot somebody who underscores (my backarrow) a point with backspaces (my lambda!!!); a problem others must feel on some displays when words get replaced with underscores. I think it's fine to talk about nice esoteric characters between consenting adults. What about finding a minimal character set that everybody can hack? I think the TTY33 set is a good start, although we needn't ban lower case or { and } since the TTY maps them to upper case and [ and ] (or at least the ones I used to use did). [Mark] -------  From: Frankston at MIT-Multics (Robert M. Frankston) Date: 11 November 1977 1254-est Subject: more on controls Message-ID: [MIT-Multics]1.2.BBBJGxCWhkhxXC To: header-people at MIT-MC 1. While I might object to tings like control-Q and ESc being used for "unintended" purposes, I find a system that can't handle backspaces to be dificient. In fact, this is part of the same problem of saying "we have seven (footnote: 7!!!! DEC screws us all by saying gee, we can show off our neat bit packing instruction set and since ASCII is only seven bits (and will never grow) we can save a whopping 12%/character on our nifty machines) (again, apologies for the tirade). The control functions are useful as long as they have standard definitions. I realize that the TELNET protocol is not quite, ASCII -- it is a more precisely defined code with the newline/linefeed ambiguity resolved (not the way I'd like but ....). Like Mark, I find it annoying when peeple obliterate important words inh messages, but save my anger for the terminal manufacturor who makes terminals that still have -< characters (left arrow in cae your terminal (probably CRT) is incapable of overprinting). If I am coming accross with a vehemence against DEC, be assured that DEC is not alone as a target. On the other hand, I have used ITS a fair amount and do like many aspects of it. In find, howver, that I am more useful in a Devil's advocate position at the moment than as a praiser. (Actually I suspect that there are still six-bit sysmtems lurking out there in the world) While rambling and reflecting on these matters, I might note the trend away from random uses of controls on the part of CRT manufacturers. DEC , for example, has adopted semistandard sequences (ESC A, ESC B ...) for cursor control on their more recent terminals as have Beehive and others. We now await Data General's second generation. Also notice DEC's recent activity on the standards committe for ASCII.  Date: 11 Nov 1977 1316-EST From: Rick Gumpertz at CMU-10A Subject: addresses To: Header-People@MIT-MC Sender: RICK.GUMPERTZ at CMU-10A Message-ID: [CMU-10A] 11 Nov 1977 13:16:34 Rick Gumpertz If I want to indicate that mail went to users A, B, and C but that one can send further notes to either D (a re-distributor) or to all of A,B, and C, what do I put in the address list?? Rick -------  Date: 11 NOV 1977 1249-PST Sender: DCROCKER at USC-ISI Subject: Re: <[Rand-Unix]10-Nov-77 18:00:53.Dcrocker> (THE VOTING RESULTS) From: DCROCKER at USC-ISI To: MOON at MIT-MC Cc: HEADER-PEOPLE at MIT-MC Message-ID: <[USC-ISI]11-NOV-77 12:49:01.DCROCKER> In-Reply-To: Your message of NOVEMBER 10, 1977 Sorry about not mentioning spaces-before-colon. This did not consistently receive votes, so I factored it in with the multiple-versus-single votes. That, no doubt, does not sit well with those who DID vote (generally in the negative). Now that I've just typed the above, I went off and recomputed the votes which could reasonably be interpreted as referencing the colong question. More were explicit that I had thought and they were not all from MIT. 6 definitely against space before colon, with one additional "possibly" against. Three definitely in favor with one additional "possibly" in favor. There are four of us on the committee, so multiple blanks remain. I really have trouble believing that, at this stage of computer science, people are still getting hung up over single versus multiple blanks. Dave. -------  Date: 11 NOV 1977 1723-EST From: DLW at MIT-AI (Daniel L. Weinreb) To: DCROCKER at USC-ISI CC: HEADER-PEOPLE at MIT-AI I do not quite understand the reasoning in this paragraph from your recent letter: Now that I've just typed the above, I went off and recomputed the votes which could reasonably be interpreted as referencing the colong question. More were explicit that I had thought and they were not all from MIT. 6 definitely against space before colon, with one additional "possibly" against. Three definitely in favor with one additional "possibly" in favor. There are four of us on the committee, so multiple blanks remain. I really have trouble believing that, at this stage of computer science, people are still getting hung up over single versus multiple blanks. At the beginning of the paragraph you are considering the question of whether spaces should be allowed between field names and the following colon; that is, requiring "To:" rather than (either) "To :" or "To :". Sometime toward the end of the paragraph, the conclusion you reach is "multiple blanks remain." I, personally, am not hung up over single versus multiple blanks. But the issue of ANY versus NO blanks still bothers me. Did the votes indicate an unbiased consensus on this question? Personally, I favor only allowing "To:" and neither "To :" nor "To :", although I agree that where single blanks are allowed at all, multiple blanks should be too.  Date: 11 NOV 1977 1449-PST From: POSTEL at USC-ISIB Subject: (Response to message) To: DLW at MIT-AI, DCROCKER at USC-ISI cc: HEADER-PEOPLE at MIT-AI, POSTEL In response to the message sent 11 NOV 1977 1723-EST from DLW at MIT-AI (Daniel L. Weinreb) the space before the colon strikes me as bad english, i am clearly no expert, and we are doing this in computerland so maybe the rules of english don't apply, but it seems to me that in english the punctuation marks are right up against the preceding character -- no space. sometimes there is one space and sometimes two spaces after a punctuation mark, but one rarely sees space before the mark. --jon. -------  Date: 11 NOV 1977 1559-PST Sender: DCROCKER at USC-ISI Subject: Pain in the Colon From: DCROCKER at USC-ISI To: Header-People at MIT-MC Message-ID: <[USC-ISI]11-NOV-77 15:59:58.DCROCKER> I have this very unusual approach to formulating features in a text system: I ask people in real-world offices whether they need/want a thing and/or whether a potential system limit will impact them. Now I know that such a heretical approach is not conducive to self-worth, since clearly my own, creative, ideas are better than what a lowly secretary can tell me, but I am afraid that my current view is to LISTEN to such people and NOT to TELL them what they need. I asked a random secretary (generally regarded as a crackerjack) whether the construction: Field1 : text of field1 Field23 : text of field23 was ever used in office environments and was told that "of course" it was. I quote the "of course" because this was another example of my conducting an informal "experiment" to assess the desires/needs of real users, as compared with proffered system behaviors, in which the subject(s) nearly bit my head off for asking such a silly question. Dave. -------  Date: 11 Nov 1977 1606-PST From: Klh at SRI-KL (Ken Harrenstien) Subject: Quote chars and discussion subject To: Header-People at MC Some input from the IBM people (Hathaway, Haines, etc) would be valuable. In particular I have no objections to "\" except that I understand Haines can't print it, so would like to wait and hear from them. Meanwhile, I would prefer to know if my comments in "last words" are considered well founded by others. Yes, the issues are tougher than quote-char selection and there are only 24 hours in our short days, but there is very little time left. The changes I would like to see can, for the most part, be made with little trouble. Exception may be the from/sender discussion which needs a firm underlying concept and some good consistent english; I'm afraid I can't help a lot there. --Ken -------  Date: 12 Nov 1977 1255-EST From: Rick Gumpertz at CMU-10A Subject: quote sequences To: Header-People@MIT-MC Sender: RICK.GUMPERTZ at CMU-10A Message-ID: [CMU-10A] 12 Nov 1977 12:55:56 Rick Gumpertz No matter what the choice of escape character ("\" seems a win. If IBM can't handle it, let them use cent-sign or something. The ARPANET is a federally sponsored project, and it is not unreasonable to expect ALL hosts to support ASCII -- they already have to do it for NVTs anyway -- in some fashion or another. I am sure each non-ASCII site can think of some convention for denoting ASCII internally. Rick -------  Date: 12 Nov 1977 1301-EST From: Rick Gumpertz at CMU-10A Subject: quote sequences (second try) To: Header-People@MIT-MC Sender: RICK.GUMPERTZ at CMU-10A (Let me try this note again) No matter what the choice of escape character ("\" seems a win. If IBM can't handle it, let them use cent-sign or something. The ARPANET is a federally sponsored project, and it is not unreasonable to expect ALL hosts to support ASCII -- they already have to do it for NVTs anyway -- in some fashion or another. I am sure each non-ASCII site can think of some convention for denoting ASCII internally.) I think it is about time we started planning some of the sequences that will be started with this escape char. Any suggestions? Rick -------  Date: 12 Nov 1977 (Saturday) 1630-Est From: STECKEL at HARV-10 Subject: BELATED VOTE To: HEADER-PEOPLE at MIT-MC 1) MULTIPLE SPACES ARE (USUALLY) INCREDIBLY AESTHETICALLY DISPLEASING, BUT THE REAL WORLD DOES USE NAME: I DO STRONGLY FEEL THAT THERE BE ONE AND ONLY ONE CANONICAL SPELLING FOR KEYWORDS, AND SINGLE SPACES (NOT HYPHENS) SEPARATE WORDS. (AGAIN A REAL-WORLD TYPE GRIPE). ONLY THE MILITARY USES HYPHENS, WHILE BUSINESS USES SPACES (AT LEAST TO MY OBSERVATION) 2) QUOTE CHARACTER - IT SEEMS MUCH EASIER TO HAVE A QUOTE NEXT THAN A QUOTE STRING. BACKSLASH IS USED ON UNIX FOR THAT SORT OF THING, AND WHILE I SYMPATHIZE WITH 4 BACKSLASHES TO GET ONE THROUGH, THE MAIL SENDER SHOULD BE ABLE IN EVEN THE STUPIDEST INCARNATION TO INSERT THEM. (SORRY ABOUT THAT LAST SENTENCE; A COMPETENT SECRETARY WOULD THROW IT OUT)  Date: 12 Nov 1977 1400-PST From: ME at SU-AI (Martin Frost) Subject: Escape character and quoting To: header-people at MIT-MC I have from time to time been under the impression that the so-called escape character is proposed for inserting various special characters (such as double quote or newline) in a quoted string (ie, a string surrounded by double quotes), as in "this is a sting with a double quote (\") in it". But occasionally someone starts talking about "using an escape character instead of quoting". An escape character isn't really being considered for entirely replacing quoted strings is it? Some people have asked for this clarification in the past, yet other people continue to make (misleading? I hope) statements like the above. Let's clarify this once and for all, please. -------  Date: 12 Nov 1977 1648-PST From: BH at SU-AI (Brian Harvey) Subject: multi-word field names, hyphens, and spaces To: header-people at MIT-MC Maybe we've already been through this, but I sense some uncertainty in earlier messages. If the standard is going to allow both THIS-FIELD: FOO and THIS FIELD: FOO then I certainly hope the two are required to mean the same thing. If this means I'm voting for FORTRAN-like syntax then so be it. -------  From: Frankston at MIT-Multics (Robert M. Frankston) Date: 12 November 1977 2011-est Subject: quick note on cheating parser Message-ID: [MIT-Multics]1.2.BBBJGxGjdDlXJb To: header-people at MIT-MC Since all field names must be anchored to the first column and since the heder ends in a null line (am I corrrect on these?) then RMS's parse can simply look at the first n characters for the particular keywords of interest like "TO" and not care about the ":" except when doing detailed processing of the line (other than just printing it). Also, while I agree that field names shuld be fortran-equivalent, i.e. insensitive to space eliminatation, the "-" should probably be considered an alphabetic character. Note that by defiing a field name to explicitly use "-", one gets the effect desired by the single space people -- names can be compared without further processing (i.e. compression).  Date: 12 Nov 1977 2126-EST From: Brian Reid at CMU-10A Subject: `Fortran-like' syntax. To: Header-People at MIT-MC Sender: BRIAN.REID at CMU-10A Message-ID: [CMU-10A] 12 Nov 1977 21:26:47 Brian Reid Dave, Ask your favorite random secretary whether REPLY-TO: REPLY TO: and REPLYTO: mean anything different. Or even whether REPLYTO and REPLY TO do, ignoring the case with the hyphen. I think that having a parser scanning to a colon but ignoring all non-alphabetic characters and converting to upper case, then truncating to the first N characters and looking up in a table, is a remarkably simple way of doing things. A value of N=12 would probably be enough for anybody, and 12 is an even multiple of the number of characters stored per word on many systems (and even on DEC if you effect the case conversion by collecting in SIXBIT, as a lot of compilers do). Brian -------  Date: 13 Nov 1977 2223-EST Sender: BRIAN.REID at CMU-10A Subject: Header fields unique in N characters From: BRIAN REID(C410BR10) at CMU-10A To: Header-People at MIT-MC - - - - I think that it would be worthwhile to include some specification of a value of N such that all header fields must be unique in the first N characters if they are to be distinguished at all. The reason that I think it is worth picking such a number is that it is very likely that many implementations of mail-reading programs will in fact use a scheme whereby they look at the first N characters, and it will be unfortunate if they pick too small an N, and wasteful if they pick too large an N. Brian -------  Date: 13 Nov 1977 2223-EST Sender: BRIAN.REID at CMU-10A Subject: Header fields unique in N characters From: BRIAN REID(C410BR10) at CMU-10A To: Header-People at MIT-MC - - - - I think that it would be worthwhile to include some specification of a value of N such that all header fields must be unique in the first N characters if they are to be distinguished at all. The reason that I think it is worth picking such a number is that it is very likely that many implementations of mail-reading programs will in fact use a scheme whereby they look at the first N characters, and it will be unfortunate if they pick too small an N, and wasteful if they pick too large an N. Brian -------  Date: 13 NOV 1977 2302-EST From: MOON at MIT-MC (David A. Moon) Subject: Header fields unique in N characters To: HEADER-PEOPLE at MIT-MC I seem to recall some comments about computer science having advanced beyond the need for such things.  From: Frankston at MIT-Multics (Robert M. Frankston) Date: 13 November 1977 2328-est Subject: Header field uniqueness to: header-people at mit-mc Message-ID: [MIT-Multics]1.2.BBBJGxKczhFMNg 1. I assume Brian was refering to header field names. 2. Dave Moon: Well computer science has evolved beyond the need for uniqueness in n-characters. But much of the discussion on headers has been about making it easy to parse heaer fields with utterly trivial amounts of programming in just about any language. After all, we spent a lot of time talking about spaces before colons which, it can be argued, is an even more trivial issue. In any case, I agree with Brian, at least for fields that are to be descriminated for (or against) in simple censoring programs. 16 or 32 seem like nice round numbers. Other bidders?  Date: 14 NOV 1977 0923-PST To: Header-People at MIT-MC From: Hathaway at AMES-67 Subject: An EBCDIC voice in an ASCII wilderness About choice of "quote next character" character: We are of course an EBCDIC host, and most of our terminals are not of the ASCII variety. However, my TELNET will handle the full NVT character set, and currently the only option for that is NVT ASCII. Some of the mappings are a bit strange, but they can all be handled on standard EBCDIC terminals. However, one incredibly minor point should be made. While an EBCDIC terminal (e.g., IBM 2741) is missing such fundamental items as brackets and braces, in addition to the more obscure things such as backslash and tilde, the IBM text printing chain does in fact have all these characters, which means that all I have to do to get a good copy of anything I deem important is to print it with a TN train. EXCEPT (note emphasis) for some dumb reason IBM chose to leave the backslash OFF the text train! As I said, a minor point. And as long as someone brought up EBCDIC and such again, I would like to re-voice a complaint I had a year ago with the original RFC724, regarding the use of such things as "TELNET ASCII". I would like to remind everybody that what is spoken by TELNET is ANY (emphasis) NVT character set that might be specified by an appropriate negotiated option, and NOT (emphasis again) ASCII! Now admittedly the only option currently defined is ASCII, and any additional options defined (e.g., EBCDIC) would probably include some dualing so that all NVT ASCII characters are de- fined. HOWEVER, it seems unaesthetic to me to define a protocol spec in terms of such things as octal (or decimal) character definitions when in fact those specifications may not be the ones being used. And also the term TELNET ASCII just grates ... Wayne PS: Dammit, looks like it's gonna be one of those weeks. I was just perusing my morning TELNET protocol spec and came across this gem of a line (while defining the NVT): "The code set is seven-bit USASCII in an eight-bit field, except as mod- ified herein." Now I'll have to go off lobbying for a change to THAT spec to read something like "The DEFAULT code set is ..." Or maybe we can just specify everything in bi-quinary? PPS: That PS was of course my way of saying "Sorry guys, you are right. I don't think you SHOULD be, of course, but ..." ------  Date: 14 NOV 1977 1501-EST From: RMS at MIT-AI (Richard M. Stallman) To: HEADER-PEOPLE at MIT-AI I don't think it matters for mail much that you can, with TELNET options, switch to character sets other than ASCII. All other possibilities, including EBCDIC, are just options, which nobody is required to support, and few sites will support. ASCII is the only thing that EVERY site MUST support. So unless we want to agree on a "mail character set" and require that all FTP users and servers must agree to IAC WILL USE-MAIL-CHARACTER-SET, we should assume that everyone is using ASCII. Of course, mail sent by MLFL doesn't go through the TELNET connection, so TELNET standards don't automatically constrain it.  Date: 14 NOV 1977 1735-EST From: JZS at CCA Subject: Re: Message archival etc To: Klh at SRI-KL cc: JZS at CCA, Header-people at MIT-AI In response to your message sent 11 Nov 1977 1347-PST Ken: You, as well as any other interested Header-people, are invited to archive messages on the Datacomputer. The archiving program has an Arpanet mailbox and is already filing Header-people correspondence on a regular basis. Individual messages can be archived simply by including the mailbox, "MARS-Filer@CCA" in the CC, BCC, or FCC list. There are two built-in format requirements here: . There must appear an originator-field which contains the field-name "From" in the message-header. . The message-body must be separated from the message-header by a blank line. Batches of messages can be archived by inserting the message-file into the body of a message sent to MARS-Filer@CCA and specifying the clue "BATCH" in the subject-field. There is an additional requirement here that each message of the batch be preceded by a line which contains a "," followed by the length of the message in bytes. (There seems to be no limit to the number of ways message-handling programs can isolate messages.) Retrievals are message-activated as well. They are initiated by sending a Retrieval Request (which is a specially formatted message) to "MARS-Retriever@CCA". Retrieved messages are mailed back, one at a time, and will appear as new mail in the requester's mailbox. I have prepared an interactive program for composing RRs which runs on Tenex (my apologies to the non's) and will put a copy in DFTP COMMON>MARS by the end of the week. I'll also put a copy in CCA's directory on SRI-KA. Elsewise, retrievals are composed as follows: . The recipient of the RR message must be MARS-Retriever -- To: MARS-Retriever@CCA . Other message header fields are ignored for now . The message body portion of the RR is used to compose Datalanguage for performing the retrieval. Its format resembles a message header - or selected portion thereof. . To retrieve all messages from one or several people, specify: From: JZS@CCA ; host specification is optional From: KLH, JZS ; means From:KLH or From:JZS . To retrieve on the basis or recipients, specify: To: Header-people ; host specification is optional To: Stefferud,DCrocker,TOM ; spaces and commas imply AND . Similary, to retrieve on the basis of SUBJECT or TEXT field words, specify: SUBJECT:RFC#733 or RFC733 ; spaces and commas imply AND TEXT:escape control techniques . To retrieve on the basis of date, the following may be used: DATE: 14 November 1977 SINCE: 1 Nov 77 AFTER:1 Nov 1977 UNTIL: 14 November 1977 BEFORE: Nov 14 77 ; for the time being, SINCE: is the same as ; AFTER: -- and UNTIL: the same as BEFORE: I hope that's enough information for a start; I'm willing to respond to questions (and will try to be prompt about it). The filer checks for mail every hour (while Tenex + Datacomputer continue to function); the Retriever checks every quarter-hour. The periodicity can be altered to meet demand - though the intent is for MARS to operate as a background job or perhaps only during extremely low-activity periods. /Joanne -------  Date: 15 NOV 1977 1340-PST To: Header-People at MIT-MC From: Hathaway at AMES-67 Subject: A rose by any other name ... Something has been bothering me about this discussion of using control characters for the "quote next character" guy, and if so, which one(s) to use. Specifically, it seems to me that you ASCII guys are just not being consistent. By way of explanation, let me mention that the control-Q that KLH sent a while back was printed to me as my standard indication of a control plus the standard ASCII name for the control, DC1. This was done locally because frankly I didn't care how the user happened to generate the control character on a TTY33, I cared what it WAS! But in all the discussion to date everybody seems to directly relate control characters to how they are typed, rather than what their ASCII meanings are. I of course know why this is the case -- control-C for example is ASCII ETX, but to a TENEXer it is something entirely dif- ferent. The consistency problem I mentioned above is that this is NOT done for all characters -- you don't call tabs control-I's, you don't call bell control-G, and so forth. And control-shift-k is also not referred to as that, but rather as ESC. Why? Because the good old TTY33 had a separate key for ESC, right? (Or rather, ALT MODE.) Anyway, the only complaint I'm voicing is that IF we are considering controls, then let's consider what they mean in ASCII, not how they are typed or what they mean to a particular system. And again I might mention that NVT ASCII specifically does NOT define most controls, so I would recommend that we stay completely away from them. (My TELNET maps them one way, yours maps them differently, and somebody else's may not even allow them through at all -- why use something that is defined to be undefined?) And finally, Ken, I just absolutely could not believe your recent com- ment that "the concept of 'control character' has an extremely standard representation for ASCII terminals as uparrow followed by an uppercase letter." No, I'm not talking EBCDIC vs ASCII or TSS vs TENEX -- I'm bothered by your statement because the character "uparrow" has not even belonged to the ASCII character set for nine years! Ah me, the joys of trying to agree on what to try to agree on ... Wayne ------  Date: 15 NOV 1977 1407-PST To: Header-People at MIT-MC From: Hathaway at AMES-67 Subject: Everything you ever wanted to see about ASCII As a great believer in experimentation over cogitation, I herewith send everybody the following eight lines, which consist of the 128 ASCII codes 0 through 127, in order, sixteen per line ...  ^_ !"#$%&'()*+,-./ 0123456789:;<=>? @ABCDEFGHIJKLMNO PQRSTUVWXYZ[\]^_ `abcdefghijklmno pqrstuvwxyz{|}~Š Anything exciting or surprising happen? ------  Date: 15 Nov 1977 1713-EST From: Brian Reid at CMU-10A Subject: ASCII To: Header-People at MIT-MC Sender: BRIAN.REID at CMU-10A Message-ID: [CMU-10A] 15 Nov 1977 17:13:17 Brian Reid I'm with Wayne. Virtually nobody really understands what ASCII is all about anymore. Whether it is worthwhile trying to resurrect the true meaning of the ASCII control characters is a separate question. However, various DEC-brainwashed hackers go running around assigning graphics to the control set (e.g. the Stanford character set) or assigning semantics to them at the operating-system level (e.g. ITS). ASCII is a code for information interchange. That's what the I and the I stand for. It contains 32 control characters, one half-control, half-graphic (the space), 95 graphics, and one mistake-corrector (rubout). The control characters are not information per se, but rather are to be used by the transmission medium to envelop and annotate the text. Many years ago DEC decided to preempt the proper use of ASCII and steal the 32 control characters as commands. That's not actually in violation of ASCII because in one sense information is not being interchanged. But it caused a mind-set wherein people see the 32 control characters as characters and not as controls. This mind set then led to stupidities like assigning graphics to the control codes (even though there exists an ASCII standard way of representing extended graphics, using SO, SI, ESC, and such). And so on. This has led to all manner of misunderstandings and further mistakes. I chuckled a lot when somebody recently complained about people underlining a character by following it with BackSpace and then Underline. The ASCII document specifically requires that character-backspace-underline print as an underlined character, and yet people who had chosen to put a printing graphic (lambda or something) in the BS slot were bitching that they weren't getting the right output. Since ASCII is the government standard, and since standards are usually good, it strikes me as being eminently reasonable to require that ARPAnet protocols be ASCII. But ASCII is more than just a character set, it is a protocol, and using a Device Control 1 or a Data Link Escape to mean `quote the next character' is a violation of those protocols, and is just as much a violation as (say) using up-arrow where caret is meant or left-arrow where underscore is meant or any of the other usual atrocities that people commit with ASCII. Brian -------  Date: 15 Nov 1977 1717-EST From: Brian Reid at CMU-10A Subject: Re: Everything you ever wanted to see about ASCII To: Hathaway at AMES-67 CC: Header-People at MIT-MC Sender: BRIAN.REID at CMU-10A Message-ID: [CMU-10A] 15 Nov 1977 17:17:17 Brian Reid In-Reply-To: Your message of November 15, 1977 As a matter of fact, your full-ASCII message logged off my job!!! One of the characters that you sent (probably a DC2 or DC4) was passed by our operating system to my terminal. The terminal acted on the character in the correct way, and proceeded to transmit the entire contents of the screen back from the terminal to the monitor (that behavior is permitted when a Device-Control code is received at a terminal). The screen just happened to contain a sequence of characters capable of logging off my job, and it did exactly that. Brian -------  Date: 15 NOV 1977 1451-PST To: Header-People at MIT-MC From: Hathaway at AMES-67 Subject: Correction about full ASCII message A small apology. It turns out that the "full ASCII" message as forwarded by MIT-MC is missing SO and SI. The reason may be that these are the last two characters on the first line and the pre- ceding character on that line was a CR without a NUL following (a wanton violation of TELNET protocol). Whatever, you probably got a lot more than you wanted anyway, right? ------  Date: 15 Nov 1977 1539-PST From: ME at SU-AI (Martin Frost) Subject: Full ASCII message To: header-people at MIT-MC To: Hathaway (I assume you didn't want two copies so...) I noticed some missing chars, but the message didn't bother me. -------  Date: 15 NOV 1977 1627-PST Sender: DCROCKER at USC-ISI Subject: Quote-next-character From: DCROCKER at USC-ISI To: Header-People at MIT-MC Message-ID: <[USC-ISI]15-NOV-77 16:27:32.DCROCKER> There has been nary a single objection to using backslash for this function, although it has been well noted that some terminals have trouble generating the character on the display or from the keyboard. That wrinkle notwithstanding, backslash will be the quote character unless some VERY strong, heavily supported arguments against it appear quickly. DC'ing your 1, 2, and 3, Dave. -------  Date: 15 Nov 1977 2027-EST Sender: RICK.GUMPERTZ at CMU-10A Subject: quote next char From: RICK GUMPERTZ(N810RG02) at CMU-10A To: Header-People at MIT-MC - - - - does backslash quote the whole CRLF or just the CR?? Rick -------  Date: 15 Nov 1977 2229-PST From: BH at SU-AI (Brian Harvey) Subject: ASCII and the Stanford character set To: header-people at MIT-MC I should know better, I guess, but I feel a need to defend SAIL's use of the ASCII controls as graphics. The general line of the defence will be this: standards are indeed fine for information interchange, but if one benefits from being locally nonsttandard, great. (I agree that the burden is on us to conform to standard externally.) On the specific question of underlining, which has been batted around a lot: many tterminals are not capable of overprinting. This is not Stanford's fault. We are capable of printing a document with backspace and underscore, on those devices which can underscore at all, through suitable software. Again, I agree that that's our responsibility; meanwhile, locally, we can have our underscore and our lambda too. (Personally, I would be happier if the inventor of the SAIL character set had kept it closer to ASCII, but I don't think it was immoral of him not to, just dumb. None of the people who've complained about the SAIL character set think that EBCDIC is immoral, do you?) Escape sequences to squeeze in more graphics are okay, I suppose, but when our terminals were built, microprocessors hadn't been invented yet, and anything requiring two bytes sent to the computer would have required two keystrokes typed by the human being as well. If you think graphics in the control codes are nonstandard, you must really love our nine-bit bytes with the two extra control bits! But I'd like to invite those of you who think that's silly to come visit us for a couple of weeks and get to use our software locally. ASCII is okay for interchanging information among dissimilar systems, but as far as actually using computers is concerned, I consider an ASCII keyboard to be on a par with slide rules, horse-drawn carriages, bloodletting, and IBM machines. This is not to say that the details couldn't be improved; MIT's adaptation of our character set keeps most of its virtues while reducing the inconvenience of getting along with lesser systems. Every so often somebody proposes changing over to their version out here, but so far we've always decided it would just be too much hassle. Next operating system. -------  Date: 15 Nov 1977 2335-PST From: MRC at SU-AI (Mark Crispin) Subject: character sets To: Header-People at MIT-MC Why is everybody talking about character sets and the "immorality" of SAIL's character set? Nobody from SAIL proposed that one of our graphics be used. In fact, people here are careful not to send messages using our special characters. I wish I could say the same for people who send messages with underlined text, which lose on most display terminals and any non-backspacing printing console. I did note that it was said that backslash might lose for IBM people, and asking the IBM people if they would be screwed by this. The most mature answer to this came from Frankston, who said he'd have to type backslash four times but could live with it for a standard. Everbody else seemed to argue back and forth about what control characters were and how they should be treated and what was wedged about other systems. I was rather surprised to see people making such outlandish statements about the terminal service on SAIL and ITS (and even Tenex) systems. Look, it isn't going to do any good saying so and so is being idiotic by using these unused ASCII codes (and they ARE unused because the function they are defined to have isn't used on the systems in question) as special graphics. I could just as well say that a system that unwittingly causes a user's job to be logged off or otherwise garbaged because s/he printed a file with "control" characters (or say a true binary file!) is idiotic. You don't have those problems with Tenex or ITS or SAIL unless you ask to have those problems, so lay off the insults. Here is what I THINK is trying to get through: . No system should send a foreign system any control character other than carriage return and line feed as a sequence. Violations may be allowed to allow consenting adults to win; ie, PDP-10's with tabs, or backspaces, or form feeds/vertical tabs, or even SAIL graphics (note that I listed these in order of how much lossage is caused--most places and terminals handle tabs in a reasonable way and PDP-10's even agree on 8-tabs; many places and terminals handle backspaces (but should be used with discretion); some places and terminals handle vertical tabs or form feeds (but the utility of this is relatively small); and few places handle SAIL's graphics). . A system receiving a control character should do something "reasonable" with it; uparrow (or caret or hat or whatever you call it) followed by the character + 100 octal is common, or any other mapping scheme is alright. Certainly a system or program should take care to avoid provoking a terminal into doing randomness on receiving an image control. . When in doubt, use common sense. If you tab, don't trust the alignment to be right unless you are only talking to a system using your form of tabs. If you backspace, you better be sure the receiver's system and terminal will do the right thing. Since most displays are non-overprinting it is a bad idea to underline; uppercaseifying a word does the same thing. The way this conversation is going, we could be arguing about the virtues of lower case and whether it is right to map lower case to upper case if the terminal cannot print it and whether it is right to use lower case at all! How about all the messages that are more than 70. characters wide? (PS; to you TTY33 users I apologize for the long lines, but I guess you're used to it by now). How about a little reasoning and less arguing just to argue? [Mark] -------  RMS@MIT-AI 11/16/77 14:26:09 SOMEONE RECENTLY ASKED WHETHER A QUOTE CHARACTER QUOTES A FOLLOWING CRLF OR JUST THE CR. ACTUALLY, IT DOESN'T REALLY MATTER, SINCE THE DRAFT ALREADY ADVISES PEOPLE THAT THEY SHOULDN'T REALLY THROW AWAY CRLFS ENCOUNTERED IN QUOTED STRINGS. THE THING THAT REALLY CREATES A NEED FOR QUOTING IS THE SPACE-FOLDING MECHANISM. WE MUST HAVE A WAY TO DISTINGUISH BETWEEN CRLF SPACE FOO AND PLAIN CRLF FOO. JUST SAYING "CRLF FOO" IS NOT ALLOWED BECAUSE THE FOO DOESN'T MAKE A CONTINUATION LINE. SAYING "CRLF SPACE FOO" IS ALLOWED, BUT IT IS NOT CLEAR WHETHER THAT "MEANS" CRLF FOO OR CRLF SPACE FOO. THE SOLUTION TO THIS IS TO SAY THAT A CONTINUATION LINE IN THE MIDDLE OF A QUOTED STRING CAN START WITH A QUOTE CHARACTER AS WELL AS WITH A SPACE. BOTH "CRLF \FOO" AND "CRLF \ FOO" ARE ALLOWED AND UNAMBIGUOUS. IF \ IS MADE A "SPECIAL" AND THUS NOT ALLOWED IN FIELD NAMES, THEN THERE IS NO POSSIBILITY OF CONFUSION: A LINE THAT STARTS WITH WHITESPACE OR WITH A \ IS A CONTINUATION LINE.  Date: 16 NOV 1977 1031-PST Sender: DCROCKER at USC-ISI Subject: Re: quote next char From: DCROCKER at USC-ISI To: RICK.GUMPERTZ at CMU-10A Cc: Header-People at MIT-MC Message-ID: <[USC-ISI]16-NOV-77 10:31:42.DCROCKER> In-Reply-To: Your message of NOVEMBER 15, 1977 Backslash only quotes the next character (i.e., the CR, in this case. However, there tend to be fewer restrictions on the inclusion of "bare" CRs and LFs than on contiguous occurrences of them. Ergo, a quoted CR is not the same as a bare one, so "\CRLF" will often be adequate to include BOTH CR and LF as data. Sometimes, "\CR\LF" will be needed. Dave. -------  Date: 16 NOV 1977 1623-EST From: KLH at MIT-MC (Ken Harrenstien) Subject: "ascii and ye shall receive" - & quote? To: HEADER-PEOPLE at MIT-MC I was going to try to throw some water on this ASCII randomness, but the SAIL people got their one-two punch in ahead of me. So I will just content myself with adding that uparrow and backarrow USED to be ascii, I believe, and many terminals were made back then. The equivalence with circumflex and underbar is just one of those facts of life that will stay around for a long time yet. [One user just complained recently that "rubout" was a poor choice of response to "confirm"-type questions, because novice users couldn't find any "rubout" key and didn't know that "DEL" was the right key. This is a case of proper terminal construction that just happens to not jibe with popular usage, I guess.] Enough. I am glad that Dcrocker has made a commitment to "\". But suddenly I am one of the confused people; are we talking about "\" quoting the next char, or as a general "escape" which can have quoting as ONE of its functions? I thought it was the latter. The latter also would ensure that the quote-CRLF issue is a non-issue, because as RMF suggested, one could define "\n" to mean newline or CRLF. Anyway, even if it is a simple "quoter", I don't see why there is any confusion about folding lines. If you want to have CRLF SP FOO in a quoted string, you just set it out as CRLF SP SP FOO, because the standard seems to say pretty clearly that the first whitespace (tab or sp), and ONLY the first one, is to be ignored. This is much simpler than having more hair surround the quote character and folding; and most importantly, simple programs don't have to worry about this quote character when skipping fields. It is only necessary to explicitly quote CR and LF in a quoted string if you want to have all non-quoted CRLF's (as from random folding) ignored. My understanding was that these are currently not to be ignored and hence don't need explicit quoting. The standard is not clear about this however; it waffles, I think. Personally I don't mind if it is made firm that CRLF's in a quoted string are part of the string. --Ken  Date: 11/16/77 1816-EST From: HAINES at LL Subject: Quoting To: Header-people at MIT-MC In our system (VM/370 CP, CMS on an IBM 370/168), the sequence in most cases is used to define the end of a record (i.e., it does not map into a character or pair of characters but rather tells the data mapping process where to terminate a record). An occurence of or outside this context simply gets translated to its EBCDIC equivalent. The mapping is done by a low level process; I believe that MAIL has no business telling a lower level of the protocol hierarchy what to do. The sequence "A\B" would result in the pair of records "A\" and "B" whereas "A\\B" results in the single record "A\\B". This may not cause any problem at all; my point is that the has a very distinct meaning that is insensitive to any quote convention that some higher level process may use. In actuality our mail receiver uses PRINT formatting where the records received from the network translator comprise a set of records that will produce the "correct" image on an IBM 1403 printer (the first character of each record is carriage control and may specify single space, double space, no space, eject, etc.). The process correctly maps any combination of , , , and . It also converts tabs according to the TENEX standard and is treated as ; all other control characters are discarded. Since all this happens before the MAIL processor ever sees the data, an escape character preceeding a control character will normally get fouled up. PS: A backslash is converted to and from a cent sign here; there is no problem with using it as a character as long as you don't care about the shape of the graphic (e.g., it will not be symmetric to /). The cent sign is used as line-delete on VM/370 so it would have to be preceeded by a double quote. Ted Haines -------  Date: 16 NOV 1977 2334-EST From: RMS at MIT-AI (Richard M. Stallman) To: HEADER-PEOPLE at MIT-AI A character-quote rather than an escape character gives you two advantages: 1) You don't need to have a table of what \x means for each x; it is obvious. 2) When in doubt, you can quote any character in a standard way, if you are afraid that not quoting it may cause some kind of lossage. Since CRLF's don't need to be quoted, the problem of whether you really want \CRLF or some innocuous \N instead is a non-issue.  Date: 17 Nov 1977 0136-EST From: Philip Karlton at CMU-10A Subject: Re: quote next if better than escape character To: Header-People at MIT-MC Sender: PHILIP.KARLTON at CMU-10A Message-ID: [CMU-10A] 17 Nov 1977 01:36:06 Philip Karlton In-Reply-To: Your message of November 16, 1977 By using an escape character, one can define one particular following character to mean quote the next character. Besides, the mail composition programs should be the only thing having to generate the escape sequences. PK -------  Date: 17 NOV 1977 1304-PST To: Header-People at MIT-MC From: Hathaway at AMES-67 Subject: A bit more on CRLF etc. I heartily agree with Ted Haines' comments that "MAIL has no business telling a lower level of the protocol hierarchy what to do." This is what I was trying to say in my complaints about using CRLF rather than NVT "newline" and so forth. There are a LOT of systems around on which TELNET does NOT simply pass one ASCII character at a time to a higher level protocol, and I feel that MAIL (and any other higher level protocol) should not use anything that is not explicitly de- fined in TELNET. As for RMS' comment that "mail sent by MLFL doesn't go through the TELNET connection, so TELNET standards don't automatically constrain it," I would like to quote the following line from the "Mail Protocol" section of the ARPANET Protocol Handbook (page 239): It should be noted that files to be mailed are transmitted via the data connection in ASCII or EBCDIC type. This seems to me another nice justification for my (often stated) position that mail header information should NOT be contained in the file itself but rather should be transmitted over the FTP TELNET con- nections. And finally, about the question of whether CRLF SP FOO is the same as CRLF FOO or what: RMS said that it is not clear whether CRLF SP FOO "means" CRLF FOO or CRLF SP FOO, and then KLH responded that "the standard seems to say pretty clearly that the first whitespace (tab or sp), and ONLY the first one, is to be ignored." Maybe I have an old version of RFC733, but mine says quite clearly in item III.B.1.a that "Unfolding is accomplished by regarding CRLF immediately followed by a LWSP-char as equivalent to the LWSP-char." It is the CRLF that is being ignored, not the LWSP-char! And this makes it also clear that CRLF SP FOO "means" SP FOO, not CRLF FOO. Of course this also makes it impossible to fold a long line except at a LWSP-char, which might make the request in item III.B.3.f a bit hard to implement for things like long message-id's. Like I said, my version may be old. But if not, PLEASE, people, let's read the spec before we start off on tangents, okay? Wayne. ------  Date: 17 NOV 1977 1406-PST Sender: DCROCKER at USC-ISI Subject: Re: A bit more on CRLF etc. From: DCROCKER at USC-ISI To: Hathaway at AMES-67 Cc: Header-People at MIT-MC Message-ID: <[USC-ISI]17-NOV-77 14:06:03.DCROCKER> In-Reply-To: Your message of NOVEMBER 17, 1977 Wayne -- The part of the spec that you quoted explains the standard way to deal with CRLFSP. However, in II.B.3.c Quoted-strings, there is the statement: Note that the official semantics therefore do not "see" any bare CRLFs which are in quoted-strings, although particular parsing programs may wish to note their presence. For these programs, it would be reasonable to interprest a "CRLF LWSP-char" as being a CRLF which is part of the quoted-string; I.E., THE CRLF IS KEPT AND THE LWSP-CHAR IS DISCARDED. (emphasis added). Bear in mind that that is an OPTIONAL (tho reasonable) interpretation). Dave. -------  Date: 17 NOV 1977 1628-PST To: Header-People at MIT-MC From: Hathaway at AMES-67 Subject: Half ASCII apologies Apologies quickly to all -- there's not a single black kettle out there, only us slightly tarnished pots. HOWEVER (emphasis my own) I still have a bone or two to pick. First of all it was not obvious to me that RMS was talking about CRLFs in quoted strings, as he had previously said "The thing that really creates a need for quoting is the space-folding mechanism." This naturally led me to believe he was talking about general folding, NOT in quoted strings. Upon rereading his note I see that the final paragraph is specific to quoted- strings, so ... Secondly, what's all this about CRLF in a quoted string? Again my version has not been updated to talk about \ and all that, but it says (again clearly -- that's ONE good thing about the spec that we all seem to agree on!) in section III.B.2 that "quoted-string" is defined as an opening quote, "qtext", and a closing quote (ignoring the quote doubling). And "qtext" is defined as ", CR, or LF, and including linear-white-space>." Therefore the only place that CRLF can appear in a quoted-string is as part of linear-white-space, and in that definition it says that CRLF implies folding. In fact, III.B.3.c SAYS that quoted-strings that are folded must adhere to the syntax of III.B.1.a, which says that the CRLF is to be ignored. Now if the SYNTAX says that X Y is equivalent to Y, why worry about what the SEMANTICS of seeing an X are? You'll never see one! Finally you have said that "\CRLF will often be adequate to include BOTH CR and LF as data." This still seems to be a violation of the spec, since (as you point out) \CR quotes only the CR, leaving the LF simply as a character in the line. But within quoted-strings (we are talking about within quoted- strings, aren't we?) the character LF is not allowed! I'm sure glad I'm leaving town tomorrow for five days! (Bet I'm not the only one, right?) Wayne. ------  From: Frankston at MIT-Multics (Robert M. Frankston) Date: 18 November 1977 1320-est Subject: Multics returneth Message-ID: [MIT-Multics]1.2.BBBJGxfDPBjPbz To: header-people at MIT-MC Apparently we are back on the net and are getting all the backlogged mail.  From: Frankston at MIT-Multics (Robert M. Frankston) Date: 18 November 1977 1338-est Subject: Cathing up -- quoting Message-ID: [MIT-Multics]1.2.BBBJGxfFPkGkhD To: header-people at MIT-MC Somewhere, quote-next-character as opposed to escaping within a quoted string seems to have gotten adopted as the standard. Did I miss something?? I notce that Gumpertz is (as of now was) asking about \. that is the type of problem I have been rying to avoid by propose escaping within quoted strings as opposed to a quote-next-character. As an escape within a string \n could easily represent an embedded CRLF (i.e. newline).  Date: 18 Nov 1977 1410-EST From: Rick Gumpertz at CMU-10A Subject: Re: Cathing up -- quoting To: Frankston at MIT-Multics (Robert M. Frankston) CC: header-people at MIT-MC Sender: RICK.GUMPERTZ at CMU-10A Message-ID: [CMU-10A] 18 Nov 1977 14:10:10 Rick Gumpertz In-Reply-To: [MIT-Multics]1.2.BBBJGxfFPkGkhD I too prefer escaping rather than quoting, but assumed I had missed something too! Rick -------  Date: 18 NOV 1977 1713-EST From: RMS at MIT-AI (Richard M. Stallman) To: HEADER-PEOPLE at MIT-AI I see people are still arguing for an escape character as opposed to a quote character on the basis of supposed problems quoting newlines. Why does anyone think there is a problem with quoting newlines? They don't need to be quoted; they can be included without the use of a quoting or escape character. Just replace each CRLF by CRLF Space, as KLH pointed out.  From: Frankston at MIT-Multics (Robert M. Frankston) Date: 19 November 1977 0951-est Subject: Once again: escape vs quote-next-character Message-ID: [MIT-Multics]1.2.BBBJGxhKGLqMMM To: header-people at MIT-MC First questions: 1. What is the status in the draft of quoted strings with the the " character? 2. Does adumb parser that screens on field names have to be sensistive to them? 3. How does the quote-next-character affect the prser? And some comments. 1. I'd like to here from Crocker on the choice of quote-next vs escape within a string. 2. In reply to recent comments on escaping, An advantage of the escape sequence is that it is not limited to something like \n for newline. One can also conceive of other extensions that may be useful in a quoted string such as \p for newpage. Yes, I know that ASCII has the newpage character, but I find it an advantge to not include what might be called "active" characters in a string that is meant to be processed before its actual use. I.e. if I print the letter, I'd like to see a \p instead of going to a newpage. the newpage should be the function of a routine (thinking now of an address field) that actually does something like printing the address on an envelop.  Date: 21 NOV 1977 1500-PST Sender: DCROCKER at USC-ISI Subject: RFC 733: Standard for the Format of ARPA Network Text Messages From: DCrocker@Rand-Unix,Vittal@bbnd,Pogran@multics,Henderson@bbnd To: Walker, Feinler at SRI-KL, Postel at ISIB Cc: Header-People at MIT-MC, [ISI]Mailing.List: Message-ID: <[USC-ISI]21-NOV-77 15:00:50.DCROCKER> RFC 733 is at last available for inclusion in the Protcol Handbook and distribution as an RFC. The document is in [USC-ISIA]Standard.Doc and is accessible via FTP by using login Anonymous and any password. The document is 38 text pages long and is fully-formatted. It has been a very long haul, since last year, and we would like to particularly thank the members of Header-People who contributed so much time offering ideas to the specification process. Dave, John, Ken, and Austin. -------  Date: 21 Nov 1977 1950-EST Sender: BRIAN.REID at CMU-10A Subject: Fake robot: a call for help From: BRIAN REID(C410BR10) at CMU-10A To: Header-People at MIT-MC, MSGRP.DST - - - - A reporter from Business Week magazine is going to Quasar tomorrow morning (Tuesday 22 Nov) at 10:00 a.m. I want him to take with him a person who would be able to exposte the thing for what it is. Are any of you folks in New York City? Would any of you be willing to go along with this reporter tomorrow morning? If so, please let me know IMMEDIATELY, and I will connect you up. Brian Reid -------  Date: 24 Nov 1977 0011-PST From: Klh at SRI-KL (Ken Harrenstien) Subject: Source compare - KSC;RFCDIF EDITED To: Header-People at MC In order to spare myself and others the pain of plowing through the entire RFC again, I have made a source compare of the "final" 733 with the previous version, and edited it somewhat to remove superfluous differences (due to page renumbering or typographical corrections). With the aid of this file it is quite easy to see what has (or has not) been changed. on MIT-MC: KSC;RFCDIF EDITED Note to Dcrocker: there are still two typos. One is "cononical" => "canonical"; the other is "Massachusets" => "Massachusetts". Oddly enough the previous version had the latter typo as "Massachussets". -------  Date: 27 Nov 1977 2349-EST From: Rick Gumpertz at CMU-10A Subject: Fun discussions To: Header-People@mit-mc Sender: RICK.GUMPERTZ at CMU-10A Message-ID: [CMU-10A] 27 Nov 1977 23:49:39 Rick Gumpertz Having just spent 2 hours getting from Boston to Coraopolis (the site of the Pittsburgh airport) but 4 hours getting the remaining 15 miles home, I may be in a bit of a strange state of mind. Anyway, it occurred to me during one of my long stops on the highway that we (Header-People, CAHCOM, etc.) sure are a lucky group. After seeing all the discussion about AM vs. PM, I hate to even think what would happen if we had to debate METER vs. METRE as the proper spelling of the unit of length. Hope you all had a happy Thanksgiving and that none of you got too badly caught in the wonderful weather now showing in a airport or drive-in near you (if you are in the east). Rick -------  Date: 27 Nov 1977 2246-PST From: MRC at SU-AI (Mark Crispin) Subject: All good things come to an end at last To: Header-People at MIT-MC After reading Rick's message, I thought I had to send one myself, if only to tell you that contrary to rumor, I survived Thanksgiving (they didn't get all the turkeys...) Well, look at all the good that was done... Several people got excellent exercises of their mailing subsystems. I expect that MIT's COMSAT is particularly well-debugged by now. I think several of us saw how wedged we can be about things that each of us might consider to be perfectly reasonable positions. Especially implementors, who normally are all-mighty and unquestioned at home, got to see what it could be like for some users in dealing with them in the course of dealing with others who are used to being omnipotent on design. I hope all the hassle has been worth it. I hope the sites which use hairy headers will keep them in their cages when sending mail to sites which don't use the hair. I'm sure the sites with one-line headers (SAIL, MIT) will keep their headers in their cages when talking to the net (although that is an interesting point! Why weren't SAIL's and MIT's headers made "official" too along with anything else? -- Before anybody goes to throttle me, I'm not serious!). We'll see. Merrie Xmas and hippy New Year! [Mark] -------  Date: 29 NOV 1977 1422-EST From: MOON at MIT-MC (David A. Moon) Subject: Wayne Hathaway's message of Nov 15 containing all the ascii characters To: HEADER-PEOPLE at MIT-MC It apparently caused the FTP servers at SRI-KL and BBN-TenexA to go totally batshit. These are sites that have more than one person on the header people mailing list; messages to people after the first were rejected with strange comments about bad syntax on previous command, bad character after command, and various words from the middle of the message taken as unknown commands. These had 501 prefices. FTP maintainers may want to take note. For reference the offending message is available in the file "MOON; .FTP DESTRY" at MIT-MC. No log in required to retriev it via FTP.  Date: 29 Nov 1977 1624-PST Sender: GEOFF at SRI-KA Subject: Re: Wayne Hathaway's message of Nov 15 containing all the ascii characters From: Geoff at SRI-KA (Geoffrey S. Goodfellow) To: MOON at MIT-MC Cc: HEADER-PEOPLE at MIT-MC Message-ID: <[SRI-KA]29-Nov-77 16:24:52.GEOFF> In-Reply-To: Your message of November 29, 1977 Tenex FTP goes batshit if you send a ^C down. I knew this would happen, but just layed low to se how long it would take before it was noticed -- I thougt it was more amusing though that it logged Brian Ried's job off of CMU. This is a CLEMENTS@BBNA feature -- so yo'll have to take the matter up with him. -------  Date: 1 Dec 1977 0858-EST From: Header-People Subject: Implementation dates for RFC 733 To: Header-People at MIT-MC Message-ID: <124726277350 PK01@CMU-10A> A new version of the local (CMU) mail reading program is coming up. A large set of mods and requested features went into the new version including a hopefully correct interpretation of 733. Changing the header format from the old to the new was a mistake: other sites probably will not be able to parse the new headers yet. In addition, I have managed to lose my pointer to expected dates of compliance to 733. I am taking an informal survey: (a) Which sites/mail-readers are able to handle the header of this message now? (b) When should a program that generates headers in this format be released for general use? PK  Date: 1 Dec 1977 1218-EST From: Rick Gumpertz at CMU-10A Subject: Your test header To: Karlton@CMUA CC: Header-People@MIT-MC Sender: RICK.GUMPERTZ at CMU-10A Message-ID: [CMU-10A] 1 Dec 1977 12:18:48 Rick Gumpertz In-Reply-To: <124726277350 PK01@CMU-10A> Who is Header-People ?? That is what your From: field said!! Rick -------  Date: 1 DEC 1977 1232-EST From: EAK at MIT-MC (Earl A. Killian) Subject: Implementation dates for RFC 733 To: HEADER-PEOPLE at MIT-MC PK was wondering whether it was wise to loose 733 headers on the world. I would like to suggest that the sooner 733 headers start being used the sooner people will modify their mail reading programs (I'm basically pessamistic: most people are lazy and won't modify their software until it stops working and they're forced into it).  Date: 2 Dec 1977 0733-EST From: Philip L. Karlton Subject: Header parsing. To: Header-People at MIT-MC Message-ID: <124727241211 PK01@CMU-10A> Note what happened to Gumpertz' name. I suspect MSG did this. PK Begin forwarded message Date: 01 DEC 1977 1236-EST From: JZS at CCA Subject: Re: Your test header To: RickGumpertz at CMU-10A cc: KLH at SRI-KL, KARLTON at CMUA In response to your message sent 1 Dec 1977 1218-EST That's what I got too. Maybe the MIT-MC re-mailer is to blame? Joanne ------- End forwarded message p.s. I sent the strange header Header-People just to see what would happen. PK  Date: 02 DEC 1977 0850-EST From: JZS at CCA Subject: Re: Header parsing. To: PhilipL.Karlton Look at what it is doing. Which mail handler do you use? PK Begin forwarded message Date: 02 DEC 1977 0850-EST From: JZS at CCA Subject: Re: Header parsing. To: PhilipL.Karlton" either went away because it was after the host or, perhaps, because > is special cased in TENEX filenames? Rick -------  Date: 2 Dec 1977 1306-PST From: MRC at SU-AI (Mark Crispin) Subject: MSG, HERMES, SNDMSG To: Header-People at MIT-MC For the record, I was asked a long while ago to try to get HERMES imported to CCA. I poked around for CCA for quite a while, including (at BBN's request) asking Walker at ARPA for permission to have HERMES. After getting it from ARPA, BBN was silent for a long time. Much later, they said they couldn't distribute it due to conflict of interest (so they said). They asked me to have CCA's bureaucrats contact their bureaucrats, I passed the message along, and there, as far as I know, the matter ended. Don't you wish we could get our work done instead of being hassled with legal gobbletygook? It's also amusing how people like BBN and DEC copyright their operating system's versions of TECO, which is an MIT product. -------  Date: 2 Dec 1977 1821-EST From: Brian K. Reid Subject: Re: MSG, HERMES, SNDMSG To: Header-People at MIT-MC CC: Philip Karlton@CMU-10A, Crispin@CMU-10A In-Reply-To: MRC's message of 2 Dec 77 13:06 CMU's RDMAIL is written in SAIL and is reasonably system-independent. The code is public and anybody who wants it can have it. I believe it to be a much nicer system than either SNDMSG or HERMES. You might want to look into stealing the code (but wait until the RFC733 changes are done, which they almost are).