Message-Id: <199704231827.OAA09006@chrome.office.aol.com>
Reply-To: KnowlesB@aol.net
Organization: America Online, Inc.
To: Keith Moore <moore@cs.utk.edu>
cc: "Alain Zahm" <zahm@sophia.sema.fr>, schaefer@nbn.com, drums@cs.utk.edu
Subject: Re: How Reply SHOULD Work 
In-reply-to: Your message of "Wed, 23 Apr 1997 10:49:25 EDT."
             <199704231449.KAA10872@ig.cs.utk.edu> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 23 Apr 1997 14:27:01 -0400
From: Brad Knowles <BKnowles@aol.net>

Your message dated: Wed, 23 Apr 1997 10:49:25 EDT
> > I have never seen a mail user reading any kind of standard.
> 
> On the Internet, it seems to happen all the time.
> Mind you, users often mis-read RFC 822, but they do try to read it.

    You've certainly been in the business longer than I have,
but I've never known of a user to read a standard.  I've known
administrators to read them (and they are typically themselves users
of the systems they administrate), but they're not what I'd call
"users".

    As far as administrators are concerned, I've run across many
that read standards, although many of them also mis-read them
(you wouldn't believe some of the complaints I've seen).


    In my experience, "users" simply want the machine to do what
they want the machine to do, the HELL with what they told it to do
(and if it doesn't do what they wanted, they expect everyone else in
the Universe to drop *whatever* they're doing to fix their problem
for them, because they are unable or unwilling to lift a finger or
spend an attosecond to try and help themselves).

    It's up to hardware/software implementors and administrators to
help make machines as user-resistant as possible (nothing is ever
user-proof), so that it is most likely to do what they actually
want, regardless of what it was actually asked to do.


    Towards that end, if there is a standard for some aspect of the
overall system, it's very important for that standard to be clear
and unambiguous.  The less ambiguous it is, the less likely it is to
be misinterpreted by system implementors and administrators alike
(and therefore less likely for users to have problems as a result
of incompatibilities).


    In our case, we have a pre-existing standard we're trying
to clarify.

    IMNVHO, it is very important for the clarification to touch on
every single aspect of the current standard, even if to say "this
is a rathole, we now know many reasons why we won't even attempt
to go there."


    If we can't come to some sort of consensus on DRUMS as to what
the clarification should say about Reply-to: and whether it's a
purely MUA issue (and therefore out of scope), then we need to take
a step back and make sure that we "clarify" that branch by pruning
it from the new standard.

    However, that said, I believe that we can make some relatively
minimal (but still useful) statements regarding Reply-to:.

-- 
Brad Knowles                                MIME/PGP: KnowlesB@aol.net
    Internet Mail Operations Technical Lead,
    for America Online, Inc.               <http://www.his.com/~brad/>
<http://swissnet.ai.mit.edu:11371/pks/lookup?op=get&search=0xE38CCEF1>