Re: Understanding response protocols

> > 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 employ "logic" to _decide_ (or 
> > equivalently, _guess_) where the message should go is not reasonable.
> How about calling it "suggest" rather than "decide" or "guess"?
>
> When I do "reply-to-all" (as my fingers are now trained to do) in my 
> MUA, it creates To: and Cc: fields according to its current "logic".  
> These fields are displayed when I construct the reply. They can be 
> seen as a _suggestion_ that those are probably the addresses I want to 
> use. And they often are. However, I have the opportunity to modify 
> them before sending the message. Surely this is what everybody wants?
MUAs vary according to how easy it is to modify those recipient 
addresses, and how much information is given to recipients to allow 
them to make reasonable choices about those recipient addresses.  In 
every Windows and MacOSX based MUA that I have seen,  (and most of the 
*x ones) and with typical screen sizes, it is cumbersome to view all 
relevant fields of the subject message while composing the reply, and 
very cumbersome to override the decision/guess/suggestion made by the 
MUA.  Copying and pasting addresses from the subject message typically 
involves a fair amount of clicking (to select/raise windows, which 
typically buries the other window you're interested in), clicking again 
(to select addresses or text), and either dragging or "copy" and 
"paste" key presses.  If you can type, transcribing the addresses is 
actually easier, but it's error prone.
So no, I don't think this is what "everybody" wants.  I think it's what 
"everybody" is accustomed to.
> What we are arguing about is a way of making it possible for MUAs to  
> improve their suggestions.
"improving the suggestions" may be the wrong tack.  I don't want MUAs 
to be more clever as much as I want them to be more transparent.
>  In particular, people want more information about the wishes of 
> original message's author with regard to replies to be available to 
> the MUA. (Reply-to: might once have been intended for this, but it has 
> been used in the wrong way, so we have to try again.)
And (at least in principle) I agree that giving authors a better way to 
convey such information to recipients might be useful, and I agree with 
giving this information to recipients, and I even agree with making it 
easy for recipients to honor that request.  What I don't agree with is 
the notion that honoring such requests should happen "by default", i.e. 
without the recipient being aware of it and choosing it explicitly.
> My MUA has only a "reply-to-all"; there is no "reply-to-list". I 
> therefore have to remember to delete Dan's address whenever I reply to
> one of his messages and NOT to delete Keith's address whenever I reply 
> to one of his. I am in danger of annoying both of them if I get it 
> wrong. My MUA has suggested that this message be copied to Russ 
> because he was involved somewhere back in the thread and his address 
> has been carried along in OPs' replies; I have no idea if he wants an 
> individual copy or not.
Lists are "interesting" for lots of reasons.  I'm starting to see that 
different people view lists in different ways - or that they project 
different sets of social conventions onto the same simple multicast 
mechanism.  Sometimes a particular list has established conventions of 
its own, at other times people implicitly or explicitly believe that a 
list "should" adhere to certain social conventions that they've 
observed elsewhere - often in meatspace.  When different individuals on 
a list have conflicting ideas as to what behavior is appropriate, we're 
not going to solve that problem with adding new fields to the email 
protocol.  (We _might_ solve the problem by explicitly establishing 
social conventions on a per-list basis, and extending the email 
protocol to communicate those conventions to list participants - but 
the main thing is to address the underlying conflict between people's 
expectations.  The mechanism is secondary.)
Because email was not designed for group discussion but as an 
interpersonal communication tool, it doesn't help its participants 
adhere to the social conventions of any particular group (even if those 
are established).   Actually it helps participants violate those 
conventions.  Traditionally, with a meatspace meeting room, you were 
either inside the room (and participating in the meeting) or you were 
not.  Along with the isolation (and privilege) inherent in the physical 
arrangement was often some expectation of focus among participants.  
Including someone outside the room in a discussion that was going on 
inside the room was generally infeasible without special arrangements.  
But with email, lists are just multicast addresses, so discussions 
routinely involve participants that might not be on the list.  And 
being "on" a list is not like being "in" a meeting room (in the days 
before laptops and WiFi) - for instance you can be "on" a list while 
still having far greater demands on your attention that aren't visible 
to other list participants.
The duplicate copies issue is separate.  It's understandable that 
people do not want to see duplicate copies of messages.  It's also 
understandable that different people want different filing arrangements 
for their messages.  But message authors (and reply authors) shouldn't 
be expected to cater to every recipient's whims about duplicate copies 
and filing arrangements.  The right thing is for the author of a 
message (or reply) is to specify _who_ should get the message (where 
_who_ includes lists and/or individuals).  Duplicate suppression and 
filing of messages should be sorted out by software that acts on behalf 
of each recipient, according to that recipient's preferences.  Letting 
the author provide hints about _who_ to reply to might be useful for 
other reasons, but expecting recipients to recognize and accommodate 
senders' preferences about duplicates and filing cannot scale.
Keith