Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site hou3c.UUCP Path: utzoo!watmath!clyde!burl!hou3c!Crispin@SU-SCORE.ARPA From: Crispin@SU-SCORE.ARPA (Mark R. Crispin) Newsgroups: net.mail.headers Subject: Re: parsing headers Message-ID: <770@hou3c.UUCP> Date: Tue, 21-Aug-84 13:17:18 EDT Article-I.D.: hou3c.770 Posted: Tue Aug 21 13:17:18 1984 Date-Received: Fri, 24-Aug-84 04:08:52 EDT Sender: ka@hou3c.UUCP (Kenneth Almquist) Lines: 21 To: Margulies@CISL-SERVICE-MULTICS.ARPA Cc: Header-People@MIT-MC.ARPA In-Reply-To: Message from ""Benson I. Margulies" " of Tue 21 Aug 84 09:06:09-PDT Postal: Systems Concepts; 520 Third Street; San Francisco, CA 94107 Phone: (415) 442-1500 x31 The difference between my position and Benson's seems to be philsophical. I mostly agree with him on his points that: . a text/envelope distinction exists . a header is a sensible printed representation of the envelope of a freshly-composed message . a header is a sensible representation to edit Where I disagree is that I do not see the necessity to require that the post-editing header remain a respresentation of the envelope. This introduces the problem which I referred to: if an "edit headers" functionality exists, which parts of that functionality affect the envelope and which don't? MM's approach to the problem is less than satisfactory. It has an "edit headers" functionality which is parsed by the reply processor with the added twist that unknown header items are treated as user- defined headers (neither good nor very robust). It then has various power tool commands to alter the headers from MM context, which know what should alter the envelope and what shouldn't. -------