Errors-to: owner-drums@CS.UTK.EDU
Message-Id: <199508161909.PAA24660@wilma.cs.utk.edu>
From: Keith Moore <moore@CS.UTK.EDU>
To: Eric Thomas <ERIC@SEARN.SUNET.SE>
cc: Jacob Palme <jpalme@dsv.su.se>, Keith Moore <moore@CS.UTK.EDU>,
        ietf-drums <drums@CS.UTK.EDU>
Subject: Re: "Reply-To" 
In-reply-to: Your message of "Wed, 16 Aug 1995 20:20:18 +0200."
             <199508161832.OAA26451@CS.UTK.EDU> 
Date: Wed, 16 Aug 1995 15:09:18 -0400
Sender: moore@CS.UTK.EDU

> 95% of what?  Our main mail server delivered  868,891 messages yesterday,
> mostly mailing list  traffic. Most of it had the  "Reply-To:" usage you'd
> ike to  deprecate.

Please be specific.  Which usage of reply-to are you talking about?

> AOL delivers about  1 million messages a  day. That's the private Internet 
> mail  from its 3 million users (for  all I know it's 1.5M and  4M since 
> the  last time I got  the figures, but  that's another story). 

Yes, AOL is big.  But I can't tell what point you're trying to make.

> Anyway, I'm afraid I'm not convinced that the "5%" you don't want
> to specify really do amount to just 5% of SMTP messages.

95% and 5% aren't real measurements, of course.  But there are so many
different expectations of how things *should* work that any behavior
that we specify will probably go against the expectations of the 
*majority* of users.  That doesn't mean we shouldn't specify some behavior.

I'm interested in changes that:

a) will allow a reasonable degree of flexibility/functionality.

The more reply-* headers we add, the more different ways there
will be to interpret them, and the less overall functionality 
we will actually obtain.  

On the other hand, we could deprecate Reply-to entirely, making 
it much easier to specify proper functionality, and therefore 
encouraging greater uniformity across platforms.  But I find 
Reply-to very useful on those rare occasions that I choose to 
specify it, and I hate to give it up.

b) won't do great harm to the installed base.

It's okay to go against people's expectations, but if the changes
we suggest result in large numbers of replies going to the wrong
place, mail not being delivered, etc., we fail.

Also, we must be careful to define reply behavior in such a way
that it's obvious to authors of mail composers and list managers 
how to get (a reasonable approximation of) the behavior they
want, given that some mail readers will implement the new rules,
and others will implement present-day rules.

To me this means, we should:

+ discourage certain present-day uses of headers, or redefine
  them slightly, rather than create new headers, and

+ recommend a particular user agent behavior that is somewhat 
  representative of current behavior.

Both of these are aimed at reducing the number of different
ways that a mail reader might act when generating replies.

Keith