Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!umich!samsung!brutus.cs.uiuc.edu!psuvax1!psuvm!DMSWWU1A!URZ02
From: URZ02@DMSWWU1A.BITNET (Dr. Klaus-Bolko Mertz)
Newsgroups: bit.listserv.mailbook
Subject: Re: BSMTP header
Message-ID: <MAILBOOK%90020615531767@DEARN>
Date: 6 Feb 90 15:19:05 GMT
Sender: MAIL/MAILBOOK subscription list <MAILBOOK@RICEVM1>
Reply-To: MAIL/MAILBOOK subscription list <MAILBOOK@RICEVM1>
Lines: 29
Approved: NETNEWS@PSUVM Gateway
X-Acknowledge-To: <URZ02@DMSWWU1A>
In-Reply-To:  Message of Fri, 2 Feb 90 12:34:41 LCL from <MICHAEL@UTORONTO>

On Fri, 2 Feb 90 12:34:41 LCL Michael Wagner said:
>
>Typing over the header is the most obvious way for someone to change
>something if they don't know much about the package (as is the case
>for most new users). Why not gently steer them back into acceptable
>usage by accepting the most obvious input?
>
>Now, granted, the typed-over input may be invalid, but the logic to
>determine that is already built-in to include/exclude. So if
>include/exclude fails, the type-over logic could re-instate the old
>header element.
>
>In fact, the command orientation of the header, combined with the
>full-screen orientation of the body, has always seemed odd to me. It
>seems to me a worthy goal to make all the full-screen editing work in
>the header as well, for those who even understand RFC822 headers. If
>you delete the last line in a header element, the comma on the
>previous line should disappear, and the header element should be
>re-checked for correct syntax. If you delete a must-exist element, a
>warning should occur, and you should be given the option of
>re-instating the essential element. And so on. If one set of commands
>(add line, delete line, etc) worked for both halves, there would be a
>smaller learning curve.

That's my feeling too, and so I hesitated for a while to switch to
89.02.0B as our all-user's MAIL. But due to other benefits I'll do
it soon.

KBM