Re: Understanding response protocols

>> Author (or author's UA per author's configuration) sets Reply-To:  
>> good.
>> List expander sets Reply-To: very bad.  RFC 2822 says "When the
>> "Reply-To:" field is present, it indicates the mailbox(es) to  
>> which the
>> author of the message suggests that replies be sent".  N.B. "author",
>> not anybody or anything else.
>
> Which is exactly why Reply-To is NOT the solution to this problem.

You are correct that Reply-To is not the solution to this problem,  
but the fact that Reply-To is better reserved for use by authors is  
NOT "exactly why" Reply-To is not the solution to the problem.  The  
reason that Reply-To is not the solution to the problem is that the  
decision about where a reply goes needs to be made by the person  
composing the reply, and NO set of header fields, no matter how you  
define them, can make this decision for that person.

> What is needed is some field that can be set by the Mailing-List  
> expander
> according to the default policy of the particular mailing list.  
> Yes, there
> need to be rules as to which takes priority when the poster and the
> expander have different ideas as to what they want, and there need  
> to be
> rules as to how the ultimate recipient can override the lot of them  
> if he
> wants to. But those are just details.

No, those aren't "just details"  - they are the most important aspect  
of getting it right.  In particular, the notion of "rules" and  
"priorities" that dictate where a reply goes is broken.  No proposal  
for solving this problem is going to succeed until it puts the person  
composing the reply in the loop.

> The usual case (95% of the time) is that both posters and  
> recipients will
> be happy to accept what the standard list policy decides.

While that may be true, it should not be inferred that the other 5%  
of the cases are unimportant, or that it's appropriate to treat the  
95% case as a default.

(95% of the time if you fall asleep at the wheel of your car, you  
will wake up before anything bad happens.  It's the other 5% that  
will eventually kill you if you make a habit of driving while asleep.)

The other thing to realize is that the 95% case (which I take to be  
an estimate of the percentage of time that a rule-based reply command  
will do what the replier wants to do anyway) isn't uniformly spread  
across mail users.  Some mail users don't participate in mailing  
lists and rarely send mail to more than one or two recipients.   
Chances are good that those users will never see a problem with Reply- 
To as it is currently implemented.  Again, the mistake is in assuming  
that what's good for that set of users is good for everybody.  They  
may even be the largest set of users, but they're not representative  
of the user population.

> They do NOT want to have to make different choices when posting on  
> account of different vagaries of different lists. They do NOT want  
> to be faced with loads of choices when replying. All they want  
> (both of them) is to press one button and have the "Right Thing"  
> happen.

It's certainly true that users don't want unnecessarily cumbersome  
user interfaces.  It's also true that at least some users want their  
computers to read their minds.  And it's also true that users don't  
like having replies go to the wrong place.

But it should not be assumed that giving people more choices about  
how to reply will make their user interfaces unnecessarily  
cumbersome.   It's not as if the only way to solve this problem is to  
put lots of different "reply" buttons on the reader window.  Actually  
as far as I can tell you want this selection to be part of the window  
associated with composing the reply, because the reply author wants  
to be able to change his mind while composing the reply about where  
the message should go, and he should be able to do this without  
having to cut and paste the subject and text of the reply that he is  
drafting.  So you might end up having only one "reply" button in the  
reader window, and a compose window that looks like:

[ Replying to: <x> author  <x> recipients < > reply-to < > list < >  
reset ]

To: [email protected], _____________
Cc: [email protected], [email protected], _____________
Subject: foo bar

The reply author could click the boxes at the top of the window, and  
the addresses in the header of the message being composed would  
change to reflect the reply author's selections.  This would make the  
selection easy and unobtrusive.

The selection box at the top of the reply compose window could also  
change color to subtly indicate changes in the default selection due  
to the presence of a Reply-To or similar field.  Or the UA could  
alert the recipient to the presence of Reply-To fields by putting a  
message at the top of the compose window for the reply.  e.g.:

+----------------------------------------------------------------------- 
-----+
| ! The message you are replying to contains a suggested Reply-To  
address.   |
| You may override this suggestion by using the buttons below.   
[options]    |
+----------------------------------------------------------------------- 
-----+
[ Replying to: < > author  < > recipients <x> reply-to < > list < >  
reset ]

To: [email protected], _____________
Cc: [email protected], [email protected], _____________
Subject: foo bar

and the [options] button could expand the pane to allow the user to  
customize the alerts on a per-sender basis, so that the user wouldn't  
have to see the warning every time he received a mail from a  
particular person who had a reply-to field in his message.  e.g.:

+----------------------------------------------------------------------- 
-----+
| ! The message you are replying to contains a suggested Reply-To  
address.   |
| You may override this suggestion by using the buttons  
below.               |
|                                                                        
      |
| < > always accept Reply-To from this author without warning  
me             |
| < > always ignore Reply-To from this  
author                                |
| <x> alert me when this author suggests Reply-To  
(default)                  |
|                                                                        
      |
| Regardless of which you select, you will always have the option  
of         |
| overriding the suggestion of a Reply-To  
field.                             |
+----------------------------------------------------------------------- 
-----+
[ Replying to: <x> author  <x> recipients < > reply-to < > list < >  
reset ]

To: [email protected], _____________
Cc: [email protected], [email protected], _____________
Subject: foo bar

A similar mechanism could be used to handle a List-Reply-To or  
similar field.

The point of this example is not to specify what the user interface  
should look like.  The point is to demonstrate that far better user  
interfaces than what we're currently seeing are possible.  We need to  
design header fields that encourage and make it feasible for better  
user interfaces to exist and evolve, rather than designing fields  
that encourage dysfunctional user interfaces.

> And the present situation is that there is NO WAY that those 95% of  
> people can do that.

I think it's incorrect to assume that anywhere near 95% of the people  
prefer a solution that sometimes does the wrong thing without telling  
them.   A rule-based system might do the right thing for 95% of  
messages, but not for 95% of users.

Keith