ietf-822
[Top] [All Lists]

Re: Understanding response protocols

2005-06-09 09:38:50

- Even when people hit the right button, (i.e. "reply to author" or
 "reply all") the behavior of an MUA in the presence of reply-to or
 other header fields is often surprising to the user, because these
 fields are either difficult to notice or not displayed at all.

In every mail agent I have used, the compose window starts out showing
editable fields for To: and Cc:. So if you don't like what it offers
initially, you just change it. 

And if you want to change between any one of
{ reply-to-author, reply-to-all, reply-to-list, reply-to-reply-to }
and another, you have to click on the original message window, copy the
addresses from a header field (which may or may not be visible), click
on the compose window, paste those addresses into the appropriate box,
and repeat for each header field from which you need to grab
addresses.  Some MUAs (e.g. Apple's Mail.app) are even worse in that
they require you to copy and paste one address at a time.  Often you
end up having to resize and/or move the compose and mail reader windows
so that you can have the relevant portions of each on the screen at the
same time.

Frankly, this sucks dead pigs through a straw.

But it's not just that editing those fields is cumbersome.  Present MUAs
don't make it adequately clear when the default behavior of a reply command
is altered by reply-to or some other header in the subject message.


Just in case it isn't clear, I have no objection to defining a new header 
field
which is set by lists (and only by lists), and which says in effect, "if you 
want to reply to the list, use this address."  However, without substantial
changes to the UIs of MUAs, such a field won't be terribly useful, and may
even be harmful if it produces less consistent behavior than at present.

We need:
1. A header to be set by the list maintainer.

Yes, but only after we get MUAs to improve their UIs.

2. A header to be set by the user, to control where replies to list go
(and in particular whether he gets a private copy or not).

HELL NO.

3. A header to be set by the user to control where personal (non-list)
replies go.

HELL NO.
 
And rules to determins which takes priority if they conflict.

HELL NO.

The last thing we need are more headers and more rules to make the 
situation more complex for the recipient who is trying to compose a reply.
 
Note that such a field is NOT the same as Mail-Followup-To, which was 
intended to be set by message originators.  Trying to equate the two 
doesn't lend credibility to your arguments.

I believe the current intention for MFT is to cover both #1 and #2. That
certainly is my reading of Jacob Palme's draft.

That would make MFT even worse than Dan's original suggestion.

Keith