ietf-822
[Top] [All Lists]

Re: Understanding response protocols

2005-06-07 12:46:46
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: a(_at_)example(_dot_)com, _____________
Cc: b(_at_)example(_dot_)com, c(_at_)example(_dot_)com, _____________
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: a(_at_)example(_dot_)com, _____________
Cc: b(_at_)example(_dot_)com, c(_at_)example(_dot_)com, _____________
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: a(_at_)example(_dot_)com, _____________
Cc: b(_at_)example(_dot_)com, c(_at_)example(_dot_)com, _____________
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