In <20040928164338(_dot_)3bc71d25(_dot_)moore(_at_)cs(_dot_)utk(_dot_)edu>
Keith Moore <moore(_at_)cs(_dot_)utk(_dot_)edu> writes:
Yes. The more I look at the problem of replies, the more it looks like the
problem is 90% UA construction and 10% protocol. Which probably means that
adding more protocol isn't the most important part of a solution. And
since adding more protocol tends to mean more complexity, doing so could
easily make the situation worse. The thing to do is to get UA functionality
right, _then_ to see what new protocol frobs (if any) are appropriate.
But the situation seems to be that you can't get the UA functionality
right without some extra protocol, because the information for the UA to
do a decent job just isn't available at present (I think few of us are
convinced by Bruce's claim that Reply-To can be made to do it all).
Moreover, if MUAs are going to be significantly changed to accomodate this
problem, then incorporating some extra protocol at the same time is
neither here nor there.
So yes, the final solution to this will contain both a protocol element
(MFT header or whatever) and a BCP component, and the BCP component may
well be 90% of it (and if a BCP is to be written for mailing lists, then
there are probably a lot of other things that could usefully be said in
it).
UAs clearly do need to show where replies will go, and insofar as they
don't do that with Reply-To now, I think that's a problem. But it's not
that they're incapable of doing that.
No, but current standards are not encouraging them to do that, and in some
cases they may even be discouraging that.
Of course, if all of the header fields were displayed, the problem would
then be one of complexity.
Actually, is is not display of Reply-To and MFT by agents that is
essential (though it is highly desirable). What is essential is for
compose windows to exhibit clearly the To: and Cc: for the reply (with
alerts and bright red colours if they are not what the user might have
expected, if you like). And the user MUST have the ability to edit those
fields before committing the reply.
But are there any compose windows out there that do not already do that?
I think it would be better if no "logic" were needed. The decision of who
to reply to belongs to the person composing the reply. For the UA to make
it easy for that person to "fill in the blanks" is reasonable. For the UA
to try to emply "logic" to _decide_ (or equivalently, _guess_) where the
message should go is not reasonable.
The ultimate decision certainly belongs there, but the average user will
surely be happy to go along with the what the original author of the list
expander asked for or whatever is the "culture" of the list. Moreover, the
average user just wants a quiet life. He just wants to hit one button,
compose his reply, and hit 'send'. He does not want to be "filling in any
blanks" in the case of what he regards as routine replies.
Yes, just occasionaly he will want to do something different, and some
users may want to do something different all the time, but MUAs should be
designed to make life convenient for the average user (though by all means
let them be configurable to do special things for users who want to be
different).
--
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl
Email: chl(_at_)clerew(_dot_)man(_dot_)ac(_dot_)uk Snail: 5 Clerewood Ave,
CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5