On Mon, 06 Sep 2004, Keith Moore wrote:
The recipient typically doesn't have a button that implements "ordinary
reply" - he has two buttons which implement
"To+Cc+(Reply-to?Reply-to:From)"
(typically labeled "reply all") and
Labelling that button "reply all" is an error, because it fails to
include the From address in the list.
"Reply-to?Reply-to:From"
(typically labeled "reply").
This button implements what I called an ordinary reply.
b) "reply to originator"
This would probably go to the Return-Path - though strictly speaking,
that's the address where errors should go. We don't really have an
address for the originator. Sender is effectively deprecated - it's
far more widely misused (by lists) than used correctly.
Sender is supposed to be the originator. Lists should leave the header
Sender alone, and adjust the envelope sender (or Return-Path). Sadly,
some don't do that.
c) "reply"
This would be like your "ordinary reply", I think - it would do the
right thing in the vast majority of cases. If defined in terms of
today's email header fields it would be something like
Reply-to?Reply-to:(To+Cc+From)
You are assuming that an ordinary reply should go to to+cc+from (if
there is no Reply-to). I assume that an ordinary reply should go to the
From address (if there is no Reply-to). I think my assumption is closer
to how things work with paper mail, but I think that both options are
useful.
- (maybe) the author should be able to specify alternate addresses
I say "maybe" because while useful for delegation, experience seems
to suggest that this is a rare case. I wonder if it's worth the
additional complexity it requires, especially if (as I am starting to
believe) overloading Reply-to to do both that _and_ excluding unwanted
recipients is a bad idea.
When I send mail with Reply-To set, what I mean is "please think
carefully before replying to any address other than the one I specified
in the Reply-To field". I suppose I'd like the recipient's user agent
to ask some kind of "are you sure?" question if the recipient invokes
any kind of reply function that would end up sending to some other
address.
[snip example]
Now maybe that's an exceptional case which isn't worth worrying about,
but it illustrates that "wrong split". Reply-to doesn't tell the
recipient or the recipient's UA _why_ certain addresses should or
should not see replies - it only tells what to do in the ordinary
case. In any case except the one the author deems "ordinary", the UA
will often do the wrong thing by default, and the recipient is left to
guess.
The recipient can be guided by natural language explanantions in the
body of the message. The UA needs to make it easy for the recipient to
specify exactly where to send the reply.
Some sort of Reply-case header might help:
Reply-case: Public discussion: list(_at_)domain ;,
Respond to author: author(_at_)domain ;,
Register for the event: secretary(_at_)domain ;
User agents would display the list of cases and ask which one (or more)
was appropriate.
In all cases I think the person composing the reply should be able
to (a) see the original addresses and (b) override the default
reply recipient list - no matter which kind of reply is chosen.
Yes, and also see which header field each original address came from.
If a user agent does all this, then I can use my own judgement to
make replies go to the right place.
I also think that such an interface would make it easier for UAs to be
more flexible about replies. Right now for the typical GUI there's a
limit on screen real estate - five reply buttons is just too many, and
if some of the least frequently used functions are placed elsewhere
they just won't be used. Putting the functionality in a compose
window (again with immediate feedback) would make it reasonable to
give the user more choices. Also, it puts the functionality where
it belongs - since choosing a recipient list is very much part of
composing a message.
I agree with what I think you are saying. A GUI user agent should
probably have one big reply button, and after you press it, you should
get a way of deciding which address to reply to, and you should be able
to change your mind before sending. A command based user agent can have
as many commands as it likes.
--apb (Alan Barrett)