Message-Id: <199512062341.SAA24666@info.cren.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 6 Dec 1995 18:45:12 +0100
To: Jacob Palme <jpalme@dsv.su.se>, ietf-drums <drums@cs.utk.edu>
From: conklin@info.cren.net (Jim Conklin)
Subject: Re: Clarify amibuities)

wants replies to be sent" is, in fact, both accurate and satisfactory.
  What we have with Reply-To is really not an ambiguity but a situation in
which the header is used in multiple, non-ambiguous ways, all of which meet
the needs of certain situations, and each of which results in the reply
mail being delivered to the address to which the sender (whether it be an
individual or an agent) intends the reply to be delivered.
  It's true that the multiple uses of Reply-To cause some user confusion
and occasional embarrasment, so a long-term replacement of Reply-To by a
multiplicity of headers may be desirable, but deprecating the current uses
will break too many current systems.  This COULD be accomplished by
providing new headers and RECOMMENDING their use instead of Reply-To for
all purposes or for all except one, instead of deprecating Reply-To in its
present uses.  I believe that the cost of this approach outweighs its
value, because I don't believe that MUA's will recognize the new headers,
and that they therefore won't be used.
  If we can convince ourselves that this is not the case, and ONLY in that
case, I would propose the new header
        List-Reply
to supplement Reply-To as the recommended header for specifying whether the
default for a reply to a list message is to be sent to the list or to the
originator of the message being distributed to the list.  Its value would
be a mailbox address, as is the case with Reply-To.

Jim

At  2:33 PM 12/6/95 +0100, Jacob Palme wrote:
> ...
>I guess everyone agrees after the discussion we have
>had, that reply-to is ambiguous. And to resolve this
>by just saying that "reply-to gives the e-mail address
>to which the sender wants replies to be sent" does *not*
>remove that ambiguity.
> ...
>If we really want to perform what we are meant to do, i.e.
>to remove ambiguities, then we will have to
>
>(1) Either select one of the ambiguous uses as the only
>permitted. This is obviously impossible to get consensus on.
>
>(2) Deprecate the whole header.
>
>(3) Replace the command with two or more new headers,
>one for each of the ambiguous meanings.
> ...