Message-Id: <199712242126.QAA11821@CS.UTK.EDU>
To: esr@snark.thyrsus.com
cc: drums@cs.utk.edu
From: "Roger Fajman" <RAF@CU.NIH.GOV>
Date:     Wed, 24 Dec 1997  16:24:32 EST
Subject:  Re:  User interface for 'reply' command

> > I don't see how it's reasonable to consider Reply-to without some thought
> > to what a user interface might be like.  The design of the protocol in
> > this case inevitably affects the user interface.
>
> Of course it does.  But the way to cope with that is not to get mired
> in endless debate over what a UI "should" look like and then hacking
> the protocol to fit the theory.

I'd say that we are already mired in endless debate about Reply-to.

Asking proponents to give an existence proof that there is a
reasonable user interface for their proposal doesn't necessarily
mean that we have to endlessly debate minor details of those
examples.  They are, after all, only examples, not requirements.

> Instead we should be asking how we can design 822bis to maximize the
> specificity of things the message *originator* can say while
> minimizing the amount of pain we require in order to transition to the
> new scheme.

There we have a difference in philosophy.  I think it's far more
important to make it easier for the replier to send the reply where
they think it should go.  After all, they are the only ones who know
what the reply says before it is sent.

Also, the vast majority of email users don't understand the concept
of specifying where replies should go when they send a message.  I
think it is rather unlikely that they ever will.

> Thus, Mail-Followup-To is a good idea, but not because it gives lazy MUA
> designers an easy hook to hang a "Group Reply" button on.  It's a good
> idea because it enables the message originator to convey a directive
> about how the message should be handled that cannot be expressed with
> Reply-To, To, and Cc; it says "These are the people I think will be
> collectively interested in replies".  And it does so without changing
> the meaning of Reply-To and breaking almost all existing MUAs.

I don't think the sender can or should be giving directives.  The
sender can make a suggestion or a request at most.

> The distinction between reasoning backwards (from a theory of UI
> design and receiver preferences) versus forwards (from a theory of
> roles and *sender* intentions) is subtle but very important, and I
> believe we have wasted a lot of time and energy here through not
> respecting it.

Obviously we disagree.