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
|
|