Margulies@CISL-SERVICE-MULTICS.ARPA ("Benson I. Margulies") (08/21/84)
I disagree with Mr.Crispin's comments. There is a distinction between text and envelope. However, a mail header is a sensible printed representation of the envelope of a new, outgoing message. It is also a sensible representation to edit. Multics allows users to "edit" the header, parses it, and then carefully prevents the user from forging those fields that are (a) part of the envelope and (b) a communication from agent to agent rather than from user to user.
Crispin@SU-SCORE.ARPA (Mark R. Crispin) (08/21/84)
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.
-------