ietf-822
[Top] [All Lists]

Re: Understanding response protocols

2004-10-15 07:53:41

On Wed October 13 2004 09:03, Charles Lindsey wrote:

In <416C7F13(_dot_)8050202(_at_)erols(_dot_)com> Bruce Lilly 
<blilly(_at_)erols(_dot_)com> writes:

Charles Lindsey wrote:
In <416B2D24(_dot_)5080009(_at_)erols(_dot_)com> Bruce Lilly 
<blilly(_at_)erols(_dot_)com> writes:

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

No, it is NOT repeated above, since you have snipped it.

It's *still* there.

You can read what's written inside the "..."?

Anybody who has been paying attention to the discussion can remember
what was claimed; others can look at the original.  Moreover the
text with the ellipsis is yours, verbatim -- now kindly apologize for
for your accusatory lie in which you claimed that I "snipped it".

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,

Why is that falacious?

As has already been explained to you, it is fallacious because list
expansion may take place (possibly multiple times) without the
knowledge of the author; you have admitted that fact, yet you
still repeat your fallacious claim.

You failed to answer my question about how the 
expander for the mailing list 'foo' could also know that the recipient
'bar' was another mailing list.

Incorrect; I answered that on October 11 -- read it again.

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 does, because they (in particular the recipients' agents) can now
see that replies are requested to be sent to both lists.

No, the semantics of Reply-To says nothing about lists or
"crossposting", and a list mailbox looks like any other
mailbox; there is no indication to any recipient or UA that any
mailbox is a list. All that can be known is that the author has
specifically recommended that responses go to some
non-empty set of mailboxes.

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.

Yes, of course there are all sorts of exceptions, but it is apparent that
many, if not most, authors want replies to go to the list in normal
circumstances.

In "normal circumstances" there may very well be no "list"
involved.  Protocols are not based on wild guesses about
what some authors might or might not want or whether or not
some mailbox is expanded to a list; they provide a mechanism
for authors to explicitly specify recommendations and provide
specified behavior in the absence of such a recommendation.

If, for particular reasons, they don't want that then they 
can set Reply-To/MFT somewhere else.

The default for a generic response (as opposed to reply-to-author,
reply-to-all, etc.) in the absence of a specific recommendation (q.v.
Reply-To) is to go to the author(s).  If an author wants responses
to go elsewhere or to additional places, it is the author's'
responsibility to set the Reply-To field accordingly.  When a respondent
wishes to send a response that includes some original message
recipient, that takes place via a reply-to-all function which also
(again, in the absence of a specific recommendation via a Reply-To
field) includes the author. And again, if the original message author
doesn't want that to happen (i.e. copies sent to him as well as to
original message recipients) -- whether an original message recipient
mailbox was expanded to a mailing list or not -- it is the author's
responsibility to provide such a specific recommendation for
responses. Remember that mailing list mailboxes are indistinguishable
from other mailboxes; the default described above (as specified in
the applicable standards) applies whether or not any mailing lists
are involved.

It is your fixation with the exceptional and unusual cases that is
blinding you to the need to get the commonly occurring cases working
smoothly with minimal intervention by users at either end.

No, Charles.  General mechanisms are being discussed w.r.t. a number
of scenarios.  You are the one with a fixation on special cases. And
you seem to fail to understand that the general mechanism also
applies to those special cases; several of which -- including mailing
lists, a.k.a. "text message teleconferencing groups" -- are specifically
mentioned in RFC 822 section 4.4.3 (Reply-To/Resent-Reply-To) [and
prior to that in RFC 733 section IV.A.2.c, and prior to *that* in RFC
724 II.C.1.b.3].  That general mechanism has been in place, with
provision for use with mailing lists as well as other uses, for a quarter
of a century; since before there was a Mail Transfer Protocol (RFC
772) or SMTP (RFC 788).  And as has been analyzed for a variety of
scenarios, that mechanism works very well when it is used. What
*doesn't* work is the assumption made by some authors that
recipients should guess what the author intends for responses --
that has been shown to be a disaster.

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.

Again, it is your fixation with the exceptional cases that is showing
through. You seem to prefer that is is better for a system to never get it
right is there is a 0.001% chance that it will sometimes get it wrong.

Please
a) define precisely what "it" means in "get it right" and "get it wrong"
b) provide hard evidence for that "0.001%" figure.

In any event, you are simply wrong; I have detailed several scenarios
including common and unusual situations.  I have shown that use
of the Reply-To field (as standardized for a quarter of a century)
works quite well; as well as can be expected by any other suggestion
made to date -- indeed I have pointed out the specific limitations
(which apply as well to other suggestions).

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

You have signally failed to convince anyone, even Keith, that the Reply-To
field provides an acceptable solution in this matter.

I see that you have now stooped (again) to putting words in
others mouths and again have failed to copy the person whom
you purport to speak for, in an unconscionable breach of
etiquette.  Keith is well able to speak for himself, as are other
list participants.
 
I have made no proposal because I see an acceptable proposal already oj
the table.

Your vision is faulty or you are having delusions; there is no
table and no proposal.