Errors-to: owner-drums@CS.UTK.EDU
Message-Id: <199508162248.SAA25323@wilma.cs.utk.edu>
From: Keith Moore <moore@CS.UTK.EDU>
To: Eric Thomas <ERIC@SEARN.SUNET.SE>
cc: Chris Newman <chrisn+@cmu.edu>, Keith Moore <moore@CS.UTK.EDU>,
        drums@CS.UTK.EDU
Subject: Re: "Reply-To" 
In-reply-to: Your message of "Thu, 17 Aug 1995 00:11:08 +0200."
             <199508162221.SAA15194@CS.UTK.EDU> 
Date: Wed, 16 Aug 1995 18:48:40 -0400
Sender: moore@CS.UTK.EDU

> You  seem to  forget that  nowadays a  lot of  mail is  sent to  computer
> programs,  as opposed  to  human  beings. Today,  "From:"  is the  person
> sending the message (and issuing the  instruction to the program).  If you
> change it to have the meaning  of the current "Reply-To:" field, you will
> break a lot of  applications and make a lot of  unhappy users. Or rather,
> your change  will be ignored  and people will continue  using "Reply-To:"
> the way they're doing today, because the customer is always right.

I don't see what problem this causes.  If the *sender* overrides the
From header when sending a request to a program, the program will
send the message to where the sender specified.  If that same request
also contained a Reply-To header, it was presumably issued by the
*sender*.  If that program happens to send a reply to the Reply-to
address rather than to the From address, it causes no great harm.
If the sender specified a Reply-To header when sending to a program,
he deserves whatever he gets.

One of the assumptions here is that Reply-To (and changing the value
of From to affect reply-to-sender-only) should be used for exceptional 
cases, not as user-specified defaults.  Users who are accustomed to 
wiring in a reply-to header on every message they send might lose out 
in the long run -- they need to specify From instead.  And user agents
need to allow users to override these headers.

The problem is that there is no agreed-on meaning of the current 
"Reply-to" field.  As I've already said, any attempt we make at 
trying to define one, and at trying to define how replies work, will 
cause some unhappy users, at least in the short term.  That doesn't
mean that we should not try to encourage more uniform behavior.

I'm looking for a set of uniform behavior that is maximally functional
without being too incompatible with the installed base.

 
> Generally speaking, you can't make a change that significantly alters the
> current meaning without  a Darn Good Reason - a  reason that sales people
> can explain to  their customers in a few minutes,  and without losing the
> sale. 

How about "it conforms to RFC XXXX"?  If by nailing a few of these things
down we add enough value at a low enough cost, people will want the thing.

I agree with you in principle that we can't severely break things, but 
neither can we improve things without annoying people here and there.

> Remember,  if you don't provide  what the users want,  someone else
> will.  It's a  free  market, and  the people  who  ultimately select  the
> standards are  the users. So you  have to make sure  that whatever change
> you are  proposing doesn't break  things users  have been relying  on for
> years.

Right.  We need to always keep this in mind.

Keith