Martin,
Thanks for the list of cases. I realize that when I wrote the comment
earlier, I formulated things clumsily, so I'd like to restate things
more precisely (hopefully) instead of replying to your points directly.
I can reply more directly in another comment if necessary.
I am not directly trying to propose policies for membership posting
rights in a mailing list. I'll explain the issue I see, and why I
think the list server should be responsible for solving it.
The main issue I see is that some people like the following custom
1) always post messages only to the list address.
While others prefer the custom
2) always post messages to the list address and the parent poster.
Variations are possible, but the "culture clash" is simplest with 1) and 2).
What is the culture clash? It appears that people who favour 1) do so
because they don't want to see duplicate messages in their MUA
systems. [I myself favour 1)] From what I understand, it appears to
me that people who favour 2) want to receive personal copies so that
they don't inadvertently miss a reply to one of their own posts.
So as a mental picture, we could say that people who favour 1) are
happy to browse mailing lists and monitor all threads equally at their
leisure. People who favour 2) aren't prepared to monitor all threads
in a mailing list, but want to know asap anything that affects them
directly, such as a direct reply to one of their posts. This is just
a mental model to fix ideas.
The clash exists because people who favour 1) cannot predict which
people favour 2) and vice versa. Or perhaps, accomodating the 2) people
would be too much work for the 1) people, etc.
I believe the clash cannot be solved at the MUA/client ends of the
network, because it requires that each list member knows something
about each other list member.
What I'm suggesting is that the mailing list server should act as a
more intelligent multiplexer, which could interface with people who prefer
the 1) custom according to the 1) custom, and could interface with
the people who like 2) according to their own preferences, etc.
To see if that is possible, we must look at the streams of messages
to and from the mailing list address, for each individual which might
interact with the mailing list in one way or another.
Now, I don't want to widen the problem unnecessarily, and my earlier
post brought up authentication and membership policies, etc.
Those things should be left for the individual list administrators.
I only want to look at how a list can technically simulate custom 1)
only for those who like that custom, and at the same time simulate
custom 2) only for those who like that other custom. People who aren't
list members could be a third category, and so on, but I'll leave that
aside for now, and I should have left it aside in my earlier post.
Simulating custom 1) for list members who like that custom:
* To send mail, a list member sends a single mail to the list address only.
* For each new mail posted to the list, the list server sends a single
copy to the said list member.
Simulating custom 2) for list members who prefer that custom:
* To send mail, the list member sends a single mail to the list address only.
* For each new mail posted to the list, the list server sends a copy
to the said list member. Furthermore, the list server checks in the
list archive to see who posted the parent message, and if the parent is
identical to the said list member, then a second courtesy copy is sent
to this list member.
This sort of system accomodates everybody at a high level, and the
cost is small (modifying list servers) compared with some alternatives
proposed (modifying everybody's MUA, or modifying everybody's
behaviour).
I'll stop this comment here rather than go into implementation
details, so as to keep the approach as clear as possible and prevent
the confusion of my previous comment. But it is clear to me that variations
of the above ideas can be thought up for non-members etc.
The question is, could such an approach solve most of the issues brought
up by various people in this discussion?
--
Laird Breyer.