Re: Different "replying" modes in a MUA

This note follows the other comments you've already received. I think my 
comments are compatible with the ones you've already received.

Some inline comments, and then more summary ones:


On 1/4/2013 8:44 AM, Jan Kundrát wrote:
> 1) If there's a List-Post header and its value is not set to "NO"
...
> 2) "Reply All" option is always available and will generate a list of
> recipients using the following rules:
>
>   - All addresses in the message's From and Reply-To will be used in the
> "To" field

Just to note this specific point: The specific language in RFC 5322 is 
somewhat milder than the original design of Reply-to and is now:

      "When the "Reply-To:" field is present, it
    indicates the address(es) to which the author of the message suggests
    that replies be sent."

Reply-to was invented to give the orignal author an explicit means for 
specifying a /replacement/ to the From address, for replies, not for 
augmenting it.

So your proposed use of /both/ Reply-To and From is not strictly a 
protocol violation, but runs counter to the intent of the author who 
created the Reply-To. In fact, that's also the intent of mailing lists 
that add a Reply-To.

At that, I think the wording from RFC733 onward is not nearly as crisp 
and complete as it should have been, to make this clear.  Sigh.


> The List-Post and the Sender headers are ignored when doing the
> Reply-All thing.
>
> The "Reply All" is the second candidate for a default (i.e. the default
> when "Reply List" is not available).

I don't quite understand what this last sentence statement means.


> 3) "Private Reply" option is always available and produces a message
> with the following recipient(s) in the "To" field:
>
>   - If the message contains a Reply-To, each of those which are at the

"each of those" ??  each of those what? Do you mean that any address is 
the Reply-to which is not also listed in the List-Post is used.


> same time *not* listed in any List-Post addresses are used. If the
> resulting set is non-empty, the From header is ignored. This means that
> any address in the Reply-To which is also listed in the List-Post is
> silenty ignored and anything not in the List-Post is used.

It appears that you intend Private Reply to mean what Reply originally 
meant:  Send this reply /only/ to the author.

The important semantic enhancement being attempted is to use information 
in List-Post to make it more likely that the reply really won't go to a 
group.  It's an interesting idea; I've no idea whether it will succeed.


Now for extended comments:

The topic really is user interface design, not protocol design.  Hence, 
the knowledge, intent, psychology and, ultimately, expectations of the 
author and the recipient are the controlling factors.  The message 
generated for the recipient should naturally reflect the recipients 
/and/ the original author's intent.

The cited Principle of Least Astonishment is a usefully concise 
reference to the question of expectation, which arguably synthesizes the 
other human factors.  One of the problems with citing the Principle is 
the implication that expectations can be readily or completely discerned.

By contrast, the rule I've observed among skilled UI designers is that 
the application of the best cognitive, usability, etc. modeling, for 
doing UI, merely produces a good /start/ and never is sufficient to 
produce a final result.  For any interesting innovation in the UI, it's 
necessary to experiment with real usage and modify as experience is gained.

Two natural assumptions drive many people's thinking about UI design:

    1)  Users always benefit from additional information

    2)  Users always benefit from having more control

For interactive interface (UI) design, both of these assumptions are 
more often wrong than right.  Too much information or being forced to 
make too many decisions both create an excessive cognitive burden.

The challenge are to get the right /balance/ of the right information 
and at the right time.  Users don't pay attention to all information 
equally or even consistently.  What I might notice today, I might not 
tomorrow.

And users essentially never do the kind of diligent address field review 
that some of the notes on this thread seems to expect.

So, your ruleset has features that are unusual and somewhat 
complicated.  In spite of the design appearing to be entirely 
reasonable, I think it highly unlikely that an average user will 
understand it or remember it.  Hence, the complexity is almost certain 
to result in... Astonishment.

One aspect of the design that's potentially interesting is to have 
interactive modification of address lists by selecting addresses to 
remove from a candidate list.  Current interfaces only allow that action 
in a kind of character-oriented text editing mode.  It sounds as if you 
want something like menu selection.

d/
-- 
  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net
_______________________________________________
ietf-822 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ietf-822