Errors-to: owner-drums@CS.UTK.EDU
Message-Id: <199508161703.NAA19942@CS.UTK.EDU>
Date:        Wed, 16 Aug 1995 18:49:06 +0200
From: Eric Thomas <ERIC@SEARN.SUNET.SE>
Subject:     Re: "Reply-To"
To: ietf-drums <drums@CS.UTK.EDU>, Jacob Palme <jpalme@dsv.su.se>
In-Reply-To: Message of Wed, 16 Aug 1995 18:13:21 +0200 (MET DST) from Jacob
             Palme <jpalme@dsv.su.se>

On Wed, 16 Aug 1995 18:13:21 +0200 (MET DST) Jacob Palme
<jpalme@dsv.su.se> said:

>Would the following definition be OK?
>
>- The "Reply-To" heading field can be used if the sender of
>- a message wants to indicate a wish that replies which would
>- otherwise have been sent to the sender are sent somewhere
>- else, such as to a secretary. The field is not meant to
>- be used to redirect replies which would otherwise have
>- been sent to a mailing list or to all recipients of a
>- multi-recipient message, and mailing list expanders
>- should not use this field to redirect replies to the list.

I'm afraid  this is  not ok at  all. You can't  take something  away from
millions  of  users  who  have  been  using  it  for  9  years  to  their
satisfaction  without providing  a replacement.  If you  can't provide  a
replacement, you can't  take away the solution people are  using now. End
users don't  care about standards. If  they need feature X  and company Y
doesn't provide it any longer because  the standards were just changed to
say that there  is no way to  do it that doesn't violate  the specs, they
will pay company  Z to do it. The  one thing they won't even  think of is
stopping their use  of a feature they want just  because a committee said
it isn't a good idea.

Personally, I think it's a lost  cause. A replacement is only useful (and
the current usage can  only be deprecated) if it is  available to a large
majority of  users. This is  going to take at  best 3-5 years.  RFC822 is
already much more complex than it needs  to, and that's the reason why so
many implementations are incorrect. If you make it even more complex, you
run the  risk of  having implementations  that do  support the  new reply
features, but incorrectly. And if that  is the case, people will continue
to use "Reply-To:" because it works  all the time. Conversely, the reason
it works all the  time is that it is very simple  to understand. If there
is  a "Reply-To:"  field and  the user  presses the  normal/default reply
button, you send the reply there.

  Eric