ietf-822
[Top] [All Lists]

Re: Understanding response protocols

2004-09-09 19:17:14


How would people feel about a strategy of clarifying a "default" 
algorithm for followup mail, and standardizing a "Wide-Reply-To" 
override?  -- Nathaniel

I am dubious of it, for the same reasons I am dubious about
Mail-Followup-To.  If the only thing anyone wants to do with it is
suppress duplicates that are  caused by mailing lists, it more-or-less
works.  But that's not the only reason people want to redirect replies. 
And when the header gets overloaded for multiple purposes, the recipient
has no way to sort this out.  Why does this header contain what it does?
 Is it  because the sender wants to eliminate duplicates, or because 
the sender thinks that discussion should naturally take place on a
particular list (and the recipient might disagree).

There really is a conflict sometimes between what the sender thinks
should happen in the event of a reply and what the recipient wants to
happen with the reply he composes.  In that circumstance, the recipient
needs to win. 

Now I agree that having recipients edit the list of reply addresses
is a rare case, but to some degree I think this is for two reasons:

1) user interfaces are still poor (but are slowly improving)
2) most people haven't been using email long enough to have developed
a shared sense of etiquette about such things such as exists for 
paper messages. (I think this will also improve)

I don't want to see the mail protocol changed to further discourage
editing of the reply list, since for many of the problems with
reply it seems like having recipients edit the reply list is the 
only way to solve them.

Also, it seems like overloading is at the heart of the problems
with Reply-To, so I'd like us to not go down that path again.

I think we are in agreement that user agents should uniformly
implement two reply functions (along with being able to edit the
reply address list);

- reply to author 
- wide reply (more or less "reply to everyone")

The first should go to From, though for the sake of a clean transition
it might be acceptable for recipient MUAs to honor Reply-To.  But use
of Reply-to in new messages should be discouraged.

The second should default to From+To+Cc.  It would be useful to provide
the sender with a way to override this - but this should be used only in
*rare* cases similar to the examples  in RFC 822: e.g. replies get
redirected to a secretary, or someone keeping track of the guest list at
a party, that sort of thing.  And when a recipient tries to reply to a
message with the override, his user agent should alert him to the fact
that this is an exceptional case - the reply isn't going to go where he
assumed it would go.  And it should give the recipient a chance to
ignore the override and send the reply to where he thinks it should go.

Because this is an exceptional case, this override SHOULD NOT be used
for duplicate suppression.  

Ideally duplicate suppression would be implemented in the recipient's
MUA (NOT the MUA composing replies) or in the recipient's message store.
One reason I believe this is that there are several other sources of 
duplicate messages than mailing lists.  Another reason I believe this
is that I think MUAs should be able to chase down threads that cross
folder boundaries (for instance between INBOX, Sent, and a list folder)
- and if they do that, they're within epsilon of being able to 
suppress duplicates anyway.

But if we really want to have recipients' MUAs suppress duplicates when
composing replies, we should do it differently than with the
Wide-Reply-To or Mail-Followup-To field.  For instance, we could have a
field of the form

Suppress-Duplicate: address1, [address2, address3, ... ]

which says that if a reply is being sent to _any_ of address1, address1,
etc., don't send a separate copy to the From address.

This would avoid overloading Wide-Reply-To (since it would distinguish
the exceptional case from the common case of wanting to suppress
duplicates), and it would allow duplicates to be suppressed even if the
recipient edited the list of reply addresses.

Keith