Charles Lindsey wrote:
In <416B2D24(_dot_)5080009(_at_)erols(_dot_)com> Bruce Lilly
<blilly(_at_)erols(_dot_)com> writes:
Charles Lindsey wrote:
In <416707AA(_dot_)1090001(_at_)erols(_dot_)com> Bruce Lilly
<blilly(_at_)erols(_dot_)com> writes:
Charles Lindsey wrote:
Which is why I said "The only place where it *can* be known ...". For
sure, if the author does not know, then there is even less chance that
subsequent mailing list expanders would know
Nota bene.
This
started with your claim -- repeated above -- that only the message
author can know when list expansion takes place.
No, it is NOT repeated above, since you have snipped it.
It's *still* there.
Now, supposing some author wants to raise a matter which is likely to be
relevant to both ietf-822(_at_)imc(_dot_)org and
IMAP(_at_)CAC(_dot_)Washington(_dot_)EDU(_dot_) ...
He can indicate that desire trivially:
Reply-To: ietf-822(_at_)imc(_dot_)org,
IMAP(_at_)CAC(_dot_)Washington(_dot_)EDU
Exactly so (or use MFT). So why have you been denying my claim that the
mailing list expanders cannot do it without assistance from the author?
That was not your claim; your claim was "The only place where it is
known that a crosspost is occurring is at the original sender.
Therefore, any information to inform subsequent agents that
crossposting is afoot HAS to be placed in the message by the original
sender." Ignoring the fallacious first statement, the second
statement is clearly not about an indication of desire or
recommendation regarding responses -- Reply-To (and the non-
standard MFT, at least according to some claims) indicates a
recommendation for responses; it does not "inform subsequent
agents that crossposting is afoot".
Yes, it is true that the author is in the best position to provide
*his* recommendation for responses, if he is willing to do so, but
that is unrelated to your claim regarding identification of if/when
list expansion takes place.
So finally you admit that my point was correct.
No, your original statement about list expansion was and remains
incorrect. Your newly stated repetition of earlier statements
made on this list by others that author(s) may provide response
recommendations via the Reply-To field is of course correct, but
it is neither novel nor related to your initial incorrect claim.
The solution to the "problem" of an author indicating his recommendation
for responses is trivially solved. You have yet to explain what "problem"
requires determining if/when list expansion takes place.
Because you want replies to go to all the lists crossposted to, without
duplicate personal copies going to people who are already subscribed to
one of those lists.
Authors do not always want responses to go to all lists in all
cases where multiple lists are involved (in some cases one list
is notified of discussion taking place on a different list, with
responses directed to the discussion list), sometimes an author
may want personal responses rather than list responses, and as
you have been informed quite clearly, not all persons wish to
be excluded from the list of recipients receiving responses
whether or not some list is involved. And in any event, there
is no standard and practical mechanism for an author to determine
who is and who is not subscribed to any particular list at any
particular time. In short, the twelve word first phrase of your
statement above is incorrect much of the time, the remainder is
incorrect at least part of the time, and the underlying unstated
assumption that an author can determine list subscription status
for others is incorrect almost all of the time.
An author can make recommendations for responses regardless of
whether or not he is aware of list expansion, regardless of
whether or not any list expansion takes place, and regardless of
whether or not any (or many) lists are involved. It is a
generic mechanism.
If an author makes a recommendation for responses to go to "foo"
and to "bar", and expansion of "foo" includes "bar" or vice
versa, or "foo" and "bar" when expanded both include "baz",
then duplicates may still be received somewhere. No proposal
(or suggestion) to date can prevent that. In the latter case
even if the author knows that "baz" results from expansion of
both "foo" and "bar" there is nothing that he can do to prevent
bar from receiving duplicates if he in fact wants his message
to go to lists "foo" and "bar" (unless he is in the peculiar
position of knowing the full expansions of both "foo" and "bar"
and is willing and able to send copies individually to at least
a subset of one list -- in which case he's not sending *to*
that list).
No amount of setting policies for individual lists, or
super-smart lists as Laird has been proposing, will bring that about.
Agreed.
The
*only* place where it can be solved is at the author's MUA.
With existing core protocols the Holy Grail of preventing all
duplicates under all circumstances cannot be achieved, via any
reasonable action that an author may take, or elsewhere, either
with existing fields or with any extensions proposed to date.
And the sort
of smartness that Dan wants to put into such MUAs, together with MFT, will
in fact do it rather nicely.
No. Even with the modifications which would be required for
MUAs and MTAs it would do no more (in the very distant long
term) than can be achieved now with the standard Reply-To
field (with its standard syntax and semantics). And that
includes the limitation noted above -- some duplicates are
inevitable under some (not particularly unusual) circumstances.
MFT also suffers from the limitation of being a one-trick
pony -- it is a special-purpose mechanism that does not
lend itself to general use (delegation, etc.).
Keith is right on several points:
1. Since we cannot achieve all things for all users under all
conditions, we ought to focus on achieving the greatest
benefit attainable with the least disruption to existing
protocols and infrastructure.
2. Duplicate suppression is best achieved near the receiving
end (MDA/MS/rMUA). [some is of course possible via some
list expanders which can be configured to recognize that
a mailbox in To or Cc fields of a message matches a mailbox
in the list expansion -- but that capability is also subject
to abuse (i.e. there are security implications), and is not
to all users' liking]
3. Some advice to UA implementors is likely to be necessary
regardless of what else is or isn't done
Keld is correct in several observations:
1. Guessing doesn't work.
2. An appropriate question is how response recommendations
can be communicated under various scenarios.
Regarding the last point, I have detailed how standard fields
expressing standard semantics with standard syntax can be used
under various scenarios identified during this discussion to
communicate such response recommendations, how such usage works
both with common "plain" reply functions as well as with
frequently-used "reply-to-all" functions, and how failure of an
author to communicate such recommendations when lists are
involved leads to a number of problems for authors, recipients,
and for third parties. It works for various list scenarios
(with some limitations for a specific identified unusual
situation), for interpersonal communications not involving
lists, for communications involving both lists and individuals,
for delegation, for authors who want individual responses to
their messages, for authors who want individual copies in addition
to list responses, and for authors who want responses to go only
to a list. It requires no changes to MUAs, MTAs, or established
protocols.
You have made no substantive comment on that. You have made
no proposal which would address the specific identified issue
of communicating response preferences. What you have done is
to make several fallacious statements with no supporting
evidence or analysis, most of which involve only a tiny subset
of the issue under discussion, and you have proposed a major
change to established syntax/semantics (changing a display
name to a keyword) which simply won't with existing standard
protocols (e.g. the Sieve protocol explicitly does not handle
named groups) and which has been widely criticized here.