Re: Understanding response protocols

In trying to project the seemingly unlimited set of possible reply 
semantics onto the visibly limited set of concepts that are 
comprehensible to the typical user, I keep coming back to the notion 
that there are really only 3 cases that are, at a first approximation, 
comprehensible to most mortals:
-- Reply to the user who sent the message.

-- Reply to the "discussion community" of the message (see below)

-- Reply highly idiosyncratically (i.e. let the user self-edit the 
headers)
That is, I'm hypothesizing (fairly confidently) that the vast majority 
of users won't be willing or able to differentiate beyond these three 
cases (and most won't even use the third).
If we eliminate the option of giving users way more options than they 
can handle, most of the complexity of this debate is then encapsulated 
as a debate over the definition of what I above call the "discussion 
community"  of a message.  I think there is a natural -- though 
grotesquely oversimplified -- tendency for users to assume that each 
message "naturally" defines such a community.  Though I think that the 
definition is neither natural nor simple, particularly given the 
baroqueness of our email protocols, I think it is our job as designers 
of protocols and systems to try, as best we can, to devise a consensus 
definition of such a community.
To put it another way, I think we should take it as a user-level 
requirement, for most users, that there can be a limited number of 
types of "reply" command, and that one of those few types should be one 
that does the best job possible of matching naive user expectations 
about the behavior of a simply named "reply to all" function (which is 
isomorphic to my notion of a "discussion community").
This is something that we worked very hard on in Andrew during the 
1980's.  Although the protocols have only become more complex since 
then, at that time we found that it was possible to devise an algorithm 
that did an extremely satisfactory job at what we then called "Wide 
Replies" using only a single non-standard extension to the email 
protocols.  The non-standard header we used was
        X-Andrew-Wide-Reply:  <addrlist>

The idea here was to permit the originating MUA (or an intermediate 
agent rewriting a message's headers, such as a list server) to use 
knowledge available at composition time to "override" the standard 
algorithm for calculating what "Reply to All" meant.  This fallback 
meant that even if our usual algorithm didn't work for a few cases, 
those cases were generally avoidable by having the originating software 
explicitly specify the wide-reply address.  (This eliminated, for 
example, the annoyingly common case of getting two copies of a message 
when someone replies to your mailing list post.  It also facilitated 
news-to-mail gatewaying by providing an email equivalent to 
"Followup-To".)
We never pushed this idea in the broader email community, but I still 
think that standardizing something like a "Wide-Reply-To" header, in 
order to gain some control on the sending side over the various 
algorithms that might define wide-reply semantics on the receiving 
side, would be a more constructive solution than a proliferation of 
user-level reply commands.  I just don't believe that users are going 
to be able to handle significantly more than a binary distinction 
(between "reply" and "reply to all"), and therefore I'd rather devote 
our efforts to making that paradigm work better, rather than towards a 
proliferation of incomprehensible options.
How would people feel about a strategy of clarifying a "default" 
algorithm for followup mail, and standardizing a "Wide-Reply-To" 
override?  -- Nathaniel