Errors-to: owner-drums@CS.UTK.EDU
Sender: Chris Newman <chrisn+@CMU.EDU>
Date: Fri, 18 Aug 1995 16:50:58 -0400 (EDT)
From: Chris Newman <chrisn+@CMU.EDU>
Subject: Re: "Reply-To"
To: drums@CS.UTK.EDU
In-Reply-To: <199508171512.LAA29261@CS.UTK.EDU>
References: <199508171512.LAA29261@CS.UTK.EDU>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Message-ID: <808779058.21217.0@nifty.andrew.cmu.edu>

I'm not sure everyone agrees on what the problem we're discussing is.  Here's
my understanding:

A) Section 4.4.3 of RFC 822 defines the Reply-to field and mentions
the use of the Reply-to field for a list-reply address as one option.

B) Section 4.4.4 of RFC 822 clearly states that when Reply-to is
present, it overrides the "from" address in the context of replies.

C) A large number of client implementors have determined that users
desire two (at least) reply functions: the "personal" reply and the
reply to "all".

D) In Section 4.4.4 of RFC 822, only a single reply function is defined.

Problem #1: When a list address is included in the Reply-to header, the
reply function defined in 4.4.4 resembles the "all" function rather than
the "personal" function.  Otherwise it is equivalent to the "personal"
function.  These two different cases cause user confusion and do not
meet the MUA needs of a large number of client implementors.

Problem #2: The "all" function is not defined in the RFC and is
implemented differently in different clients.  A "Reply-To" header may
or may not allow the sender (or list exploder) to recommend a
redirection for the "all" function (varies by MUA).


I believe DRUMS should solve problem #1.  I believe problem #2 may be
partially outside the scope of DRUMS, but nevertheless is something
the IETF needs to address.

Any amendments/corrections to this problem statement?
-----
Chris Newman <chrisn+@cmu.edu>, http://www.contrib.andrew.cmu.edu/~nifty/
The worst thing about censorship is: [censored]