Re: Understanding response protocols

> >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.
> 
> But nobody has ever suggested that the person composing the reply should
> not have the final say.

Actually, that's not true either.  But I don't think this view is widely held,
and to name names would be to invite digression into a pointless discussion 
about who said what and what he meant by that.  Let's not go there.

> But if you want to provide hoops and popups to ask the user
> 
>    "The original sender wants you to send your reply to X, but you should
>    should be aware that you have a God given right to to send it somewhere
>    else, and you are advised to consider your options carefully before
>    just hitting 'send'."
> 
> then the 95% of people who are happy to just hit 'send' will be mightily
> pissed off.

Well, duh.   If you _try_ to make an annoying UI, of course it's going to
piss people off.  It's certainly possible to botch this UI so that it's annoying 
to the user, but it's not at all difficult to do well.  Which is why I provided
(if you cared to read it) an example of how it could be done _without_ hoops
or popups and without excessive or condescending dialogue. 

> Currently, we have the Reply-To header, and the usual behaviour of MUAs is
> to reply to that address when you hit 'send'.

Which - without a clear indication to the user that the result will be surprising,
and without an easy way for the user to override that behavior - is thoroughly
broken.

> All that is suggested is that there should be some further header(s) with
> the same property, namely MUAs will reply to that address when you hit
> 'reply-to-list'.

Which is even more broken (i.e. more complex, harder to use correctly)
than the current behavior.

(well, actually it's not "all that is suggested" - it may be all _you_ are 
suggesting at the moment but the number of harebrained ideas for fixing
reply is rather large.)

> Both Reply-To and MFT/whatever are headers provided by the original sender
> and/or the mailing list manager with the intent of influencing where
> replies should be sent. The first is existing practice and the second is a
> proposed future practice.

But experience indicates that existing practice is broken, so it's reasonable
to assume that further extensions along those lines will also be broken.

Also, there's a difference of opinion about whether MFT should be used
by lists.  Not surprisingly, the same kind of brokenness that's been
been observed with the use of Reply-To by lists seems to occur when MFT
is used by lists.

> But in both cases, it is reasonable to suppose that 95% of repliers will
> just hit the proper key and accept the default behaviour.

Your characterization is overly simplistic and contradicted by experience.

- When faced with multiple reply buttons, people often fail to use the right 
  one even when they are aware of it.  Since 9X% of the time people
  hit one button, they tend to hit that button without thinking even for the
  cases when it's not appropriate.

- People often end up wanting to change the recipient list of a reply 
  after they have started composing the text of a message, indicating that the 
  "push the right reply button before you compose" model is broken.

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

- Often this surprising behavior isn't noticed until after the message is 
  sent, when it's too late to change it.

- It's not as if 95% of repliers want to do the same thing in every case.
  You need to look at a spectrum of repliers and what they want to do
  with a spectrum of mail messages.  It also should not be assumed that
  the remaining 5% of cases (or however many cases) are insigifnicant.
  Small mistakes in communications can have large consequences.

> If you are complaining that you do not like such behaviour for MFT, then
> logically wou must admit that you do not like it for Reply-To either. In
> that case, your quarrel is with implementors of existing MUAs, and if you
> want to start a campaign to have chem change their user interfaces, then
> go ahead.

I have two goals:

1. to change the behavior of existing MUAs
2. to discourage further brain-damage in MUA and header field design

They're not mutually exclusive, and they're related.

> But no way is your argument a valid objection to having another header, in
> addition to Reply-To, whose behaviour is broadly similar to Reply-To.

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.

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.

Keith