Re: Different "replying" modes in a MUA

> (oh wow.  here we go again.)

Indeed.

> 1. I disagree with the RFCs about this, and always have.   (I state this up
> front just to make it clear that I am not proposing a novel way of interpreting
> the RFCs; I'm just saying that I disagree with them.   So there's no need to
> try to reconcile my view with what the RFCs say - we're just diametrically
> opposed.)

While I agree with almost all of your subsequent points, I'm not convinced
this constitutes a position that is "diametrically opposed" to what the RFCs
say.

> 2. Regardless of the presence or absence of Reply-To or any other field, it
> is ALWAYS the recipient's job to decide to whom he wants to address replies.

Quite correct. In the case of replies user intent is very complicated and
at best can be approximated by a small set of UA settings.

> 3. It is the job of the recipient's mail user agent ("agent" = acting on the
> recipient's behalf) to obey the recipient's wishes.   In particular, (a) it
> should allow the recipient to reply to whomever he wishes to reply and (b) make
> that behavior as obvious to the recipient as possible, so that the MUA's
> behavior will be unsurprising to the recipient of the subject message (the
> author of the reply).

That summarizes the requirements I personally have for a UA in this regard very
nicely.

> (Note that "to whomever he wishes to reply" might include addresses from any
> of the headers of the subject message, and/or addresses  that don't appear in
> the subject message at all.)

> 4. UAs that change their behavior based on the presence or absence of fields
> in the subject message (especially fields that aren't normally displayed)
> generally FAIL to meet the "unsurprising behavior" test.

I'll also note that it's one thing to pull an address out of a field that's
displayed by default. At least in that case the user knows where it came from,
and has a little context as to what it means. It's quite another to pull it out
of field that isn't displayed. This can be a real surprise. 

And since most users agents don't allow the set of fields displayed by default
to be altered, the worst cases of this problem can't even be ameliorated.

> 5. It's not unusual for a recipient to want to change the set of recipients
> of a reply, after starting to compose the reply, but before sending it.  (For
> that matter, it's not unusual for the recipient to want to change the set of
> reply recipients after sending the reply, but Internet Mail wasn't designed to
> deal with that.)

I'm not sure how popular it is, but I personally do it all the time.

> 6. The best address to which to send a reply is not something that can
reliably be determined from the headers of the subject message.   Only the
author of the reply understands the reason for replying to the message, and
therefore only the author of the reply understands to whom the reply is best
addressed.

As I noted, this is why your second point is so important.

> There's a natural tension here between the expressed interests of several
> parties: the author of the subject message, the author of a reply to that
> subject message, and any lists through which that message might have been sent. 
> But the thing that makes the most sense, and produces the least surprising
> behavior, is to always entrust the author of the reply with deciding who should
> receive the reply.

Agreed.

> ---

> now, having said that, here's what I'd recommend:

> 1. There should always be "Reply" and "Reply All" buttons, even if the two do
> the same thing.

Agreed.

> 2. If there's a List-Post header in the subject message, adding a "Reply
> List" button makes sense.

I'll also note that it is important that the field be checked prior to offering
the option. The choice of a URL for the list-post field  syntax along with
providing essentially no guidelines as to its use is a bit unfortunate.

> 3. The recipient of the subject message (i.e. the author of the reply) should
> be able to change the list of recipients at any time prior to sending the
> reply, including being able to toggle between Reply/ReplyAll/ReplyList, adding
> additional recipients, and removing others.

An ancillary question that needs to be answered here is whether or not changes
made at this point should affect other header elements. I'm inclined to think
the answer is "no", but I'll note that there are potential security issues when
addresses that would normally be included in the reply are removed but message
ids associated with those addresses remain.

> Note: The Reply-To field just confuses things because it doesn't really allow
> the sender to specify his preferences as to where replies should go; it only
> takes the place of From.   But that behavior is so well-entrenched and widely
> expected that you probably shouldn't change it.   So when the recipient hits
> "Reply" or "ReplyAll" to a message for which a Reply-To field is present, you
> should use the address(es) in the Reply-To field instead of those in the From
> field.   But you should still allow the recipient the option of replying to the
> address(es) in the From field, even when the Reply-To field is present.

My personal preference is actually to ignore reply-to when doing a replyall,
but I recognize that's a distinctly minority taste.

> The best way I've thought of to do this is for the compose window to present
> filled-in message headers listing all of the possible recipients, with the
> currently selected recipients in black and the others grayed out.   So if the
> recipient hits "Reply" then the only addresses initially shown in black are
> those from the Reply-To field (or the From field if no Reply-To field was
> present).   But any address could be toggled from black-to-gray or vice versa
> by clicking on it.   And the Reply / ReplyAll / ReplyList buttons should still
> be present in the compose window of the reply, so that the recipient can easily
> reset the set of active recipients to any of those defaults.

I like that idea.

				Ned
_______________________________________________
ietf-822 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ietf-822