Message-Id: <199712270627.BAA03783@spot.cs.utk.edu>
From: Keith Moore <moore@cs.utk.edu>
To: Jacob Palme <jpalme@dsv.su.se>
cc: IETF working group on revision of mail standards <drums@cs.utk.edu>,
        moore@cs.utk.edu
Subject: Re: How to find a solution 
In-reply-to: Your message of "Wed, 24 Dec 1997 11:25:15 +0100."
             <v03110703b0c69181dd6d@[130.237.150.138]> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sat, 27 Dec 1997 01:27:22 -0500
Sender: moore@cs.utk.edu

> (1) We should find a solution which most people approve, and few people
>     strongly disapprove, rather than finding the solution which a rought
>     consensus finds to be the absolutely best solution.

A "solution" has to be deployable, and this requires that the vast
majority of implementors agree to deploy it.  It's more important that
the solution be deployable than that it be "best".

But a "solution" also has to solve some problem, and it should be
better than the status quo.  Otherwise, what's the point?

> (2) Solutions which do not accept implementations to provide two reply
>     commands or command variants, "reply-to-author" and "reply-to-group",
>     will never work because most implementors obviously want to provide
>     two such commands.

I agree that it's natural to provide those two commands, and that they
seem to correspond with the vast majority of user choices.  (though
our expectations are of course conditioned by our tools)

But a UA that tries to automatically interpret reply-to, with *only*
those two commands and no other way for the responder to be aware of
the UA's implict choice and override it, is demonstrably
dysfunctional.  This only gets worse if you add new Reply-* fields.

I don't think a standard should dictate UA behavior, but I also don't
think we can fix the majority of the reply problems unless UAs
improve.  So I generally want to encourage better UA behavior without
making such behavior required by any standard.

> (3) Solutions which try to force implementors to provide a complex user
>     interface where users are forced (not allowed, allowed is OK) to
>     make an individual decision on each potential recipient will not
>     work because implementors are obviously not willing to develop such
>     interfaces (because users find them cumbersome).

In general, I don't think a standard should force implementors to
provide *any* particular kind of user interface.  

However, it's not at all clear that such an interface is necessarily
more "cumbersome" than some of the present widely-used approaches: (a)
allowing responders to edit their recipient lists with a text editor
without seeing the original headers, and (b) sending responses to
unintended recipients and suffering the consequences.

> (4) Solutions which forbid mailing list owners from adding information
>     to guide replies to the list will not work, since mailing list
>     owners are obviously not willing to heed such rules. If, however,
>     mailing list owners are given better options for doing this
>     guidance, those options might become acceptable.

Agreed.

> What I have written above is mainly in response to what Keith Moore
> has written, since my impression from what he has written is that he
> wants solutions which do not adhere to rules (2), (3) and (4) above.

Sorry to disappoint you :)
Perhaps this note will help clear things up.

Keith