Keith says that users can control replies with Reply-To (in the absence
of reply-to munging). I agree. However, users currently have no way to
control followups.
True. But you haven't demonstrated that followups are (a) significantly
distinct from replies and (b) worth having.
Keith then suggests that there's no need for users to control replies
and followups separately. That's absurd.
Not if there's no good reason to have followups (as distinct from
replies) in the first place.
One of the big munging harms
discussed in http://www.unicom.com/FAQ/reply-to-harmful.html is the
user's inability to control replies.
Yes, but the same problems and more would exist for followups if followup-to
were defined, because lists would mung those as well.
Oddly enough, the best way I can see to get lists to stop munging reply-to
is to define some sort of list-reply-to header and get UAs to support that.
This would still be confusing to users, but at least there would be a
clear separation of function - reply-to is specified by the message
author, and list-reply-to is specified by the list that you received
the message from. And it wouldn't stop reply-to munging entirely, but
it might decrease its
incedence.
Next Keith proposes using Sender in place of From, using From to control
replies, and using Reply-To to control followups. This is a massive
change from the RFC 822 Reply-To semantics supported by dozens of
existing clients. The transition would be a disaster.
This is of course not what I had in mind. Part of your confusion is
due to your insistence on a notion of followup as separate from reply,
even when interpreting a message that I wrote. Since I don't believe
that there is a significant difference between these operations,
I obviously would not propose "using Reply-To to control followups".
There's a difference between a human making an intelligent choice
about where she wants her replies to go,
Here Keith is referring to people deleting recipients from followups.
Nope. I don't believe in followups as distinct from replies.
The problem is that these people don't have the information they need:
are those recipients members of the mailing list? The result is that
non-subscribers are often accidentally removed.
If someone replies to a message addressed to both me and this mailing list,
they shouldn't be trying to figure out whether I'm on the mailing list. I am
on this mailing list, but I don't receive mail from this list at the same
address that appears in the From field of mail I send. If someone deletes me
from the recipient list of a response because they assume I'm on the mailing
list, chances are that I won't see the response anytime soon.
And if a followup-to field were introduced, lists would add or mung
that field also, along with reply-to.
If Keith doesn't understand why Reply-To munging happens right now, he
should read http://www.unicom.com/BBS/bbs_forum.cgi?forum=replyto. The
more clients that support a followup field, the less motivation there is
for this type of munging.
I understand why Reply-To munging happens (actually there are lots of
reasons), but I disagree that adding a followup-to header will
actually lessen the degree of header munging, or simplify things
for the user, or increase the probability that hitting a single
button on the user's UA will do the right thing.
A UA that blindly copy followup-to to followups, creates much the same
problem as list robots that blindly mung reply-to.
If Keith doesn't understand the harms caused by Reply-To munging, he
should read http://www.unicom.com/FAQ/reply-to-harmful.html.
I pretty much agree with everything in Chip's statement, and have
publically expressed support for it in the past. Your implication
that I don't understand his argument is disingenuous.
Followups are an artifact of the netnews environment, where you have
separate address schemes for email and netnews.
Nonsense. Replies and followups are fundamentally different operations.
please explain what's different about them in a way that doesn't
either: refer to netnews or change the definition of reply and reply-to.
Practically every mailer supports both replies and followups.
Perhaps every UA that supports netnews supports both replies and followups
(at least for netnews), but none of the email-only UAs that I've used
support both.
Most UAs support reply-to-sender and reply-to-all, with some variation
as to (a) whether "reply-to" is used instead of the "from" address,
or as the "default" recipient list, and (b) the definition of "all"
(does it include cc addresses or just to addresses?)
I think we'd be better off defining "reply" and "reply-to-all" in
terms of existing to/cc/from/reply-to headers, than to add new
headers in the mix.
This has nothing to do with the difference between mail addresses and
news addresses.
having two different address schemes creates lots of problems.
I agree. One solution is to integrate the newsgroup address space into
the mail address space. Here's a working example:
To: djb(_at_)koobera(_dot_)math(_dot_)uic(_dot_)edu,
sci(_dot_)crypt(_at_)pubnews(_dot_)demon(_dot_)co(_dot_)uk
It would be easy to set up a global usenet.news domain, configured
locally to talk to a nearby NNTP server.
I wouldn't mind seeing something like that, though it would be really
difficult to get people to agree on a domain name for news.
(technically it may be easy; politically it would be very difficult.
locally-configured domain names aren't supposed to exist. don't
try to argue otherwise; this is an old war and reopening it won't
get anywhere useful)
Easier would be to establish a convention for domain literals,
e.g. sci(_dot_)crypt(_at_)[news:] or keith_moore(_at_)[fax:+14239748295]
Newsgroups are simply high-volume mailing lists with many entry points
and a fancy distribution mechanism.
But in the email world there's no inherent distinction
between "public responses" and "private responses" and it's silly to
pretend that there is one.
Every popular MUA supports both replies and followups.
Depends on what you mean by followups.
You can define some notion of "followup"
for email using a followup-to header, but doing so doesn't add any new
services -- it just replicates services that already exist.
False. It provides a direct way to control followups;
circular argument. Having X would provide a way to control X.
to which my response is: Not having X would rid me of the need to control X.
unless you can give me a much better justification for X, I'm quite sure
that I'm better off without it. (and no, the fact that something called
X apparently exists on some UAs, which is almost certainly implemented
differently on each UA, and also differently than what you propose, is
not a justification for perpetuating X or standardizing X')
Explanation, please. Who exactly would be confused?
Besides you? (sorry, that was too easy.)
I find this comment rather amusing, given the number of ridiculous
statements that Keith has made in this discussion---claiming that the
followup field is for MLMs to set, claiming that the widely recognized
problem of duplicates doesn't exist, claiming that the problem is solved
by MUA duplicate elimination, etc.
Your mis-statement of my position provides more evidence of your confusion.
Users who are confused by existing reply options would be even more confused
by the addition of followup options which basically do the same thing
as replies.
[ ... ]
Support for followup-to would require that UAs add other commands
("followup", "set followup-to") in addition to the set above.
Here Keith makes yet another stupid mistake: he seems to think that
followups are something different from the MUA's existing ``wide reply''
or ``group reply'' or ``reply to all'' feature.
Absolutely they are. Reply-to-all doesn't recognize a followup-to
header, and the operation that you're proposing would recognize such
a header. If such an operation were implemented, I would still
need a different operation to allow me to send a reply-to-all WITHOUT
looking at the followup-to field, because I might have reasons
for not following the author's suggestion of where I send my responses.
Above you stated that followups and replies are fundamentally
different operations, and now you're telling me that followup
is no different than "reply to all". For a large number of users,
"reply" is no different than "reply to all".
One wonders how many times Keith needs to see the problem statement
before he understands it. Here it is again:
Right now, when someone _follows up_ to a mailing list message from a
subscriber, the subscriber and the mailing list are both in the
followup's recipient list by default.
The obvious fix is to let the subscriber override the default _followup_
target, omitting his own address.
Your problem statement uses an undefined term, and so is meaningless.
If I choose a definition for that term, you'll pick a different
definition and claim that my arguments based on my defintion are
stupid.
And if I equate your word "followup" to my UA's "reply-to-all" command,
the author of the subject message does have the ability to override
the default recipient list of "reply-to-all", using reply-to.
I realize that many UAs don't handle "reply-to-all" this way,
in particular a lot of UAs use Reply-to only as a replacement for From.
But the DRUMS document already clarifies that reply-to is the author's
preference as to where replies should be sent. Adding yet another
header to define replies provides marginal additional value at best,
and increases the complexity (and variation among UAs) as to how
recipients can respond to messages. It's not worth it.
Explanation, please. How exactly would a followup field hurt anyone?
I've already explained this.
Nonsense. Keith has explained bad consequences of two red herrings:
first, having MLMs munge the followup field; second, having followups
distinguished from reply-to-sender-and-recipients.
And you completely ignore my argument against unnecessary complexity,
by citing points irrelevant to this argument and calling them red
harrings.
First explain how "followup" would differ from "reply", beyond the
fact that it would use different header names and that it's not
supported by any of the installed base.
Nonsense. It's supported by most, perhaps all, of the installed base.
It's even supported by Berkeley Mail.
Okay, but whatever that operation is, it doesn't recognize a followup-to
header, and we're better off without one. If someone modified Berekeley
Mail to support a followup-to header, I'd end up manually editing headers
even more often than I do now.
Also please explain why it
would not suffer from the same problems that reply suffers from.
The motivation for reply-to munging is that, in its absence, a typical
user has no easy way to follow up without the problem of duplicates
discussed above.
The problem of duplicates won't be solved by a followup-to header,
in any way that couldn't be solved by use of reply-to.
Let's take this message as an example. If my preference is for replies
to this message to go to me only, I can set "reply-to:
moore(_at_)cs(_dot_)utk(_dot_)edu".
If my preference is for replies to go to the 822ext list only, I can
set "reply-to: ietf-822(_at_)imc(_dot_)org". If my preference is for replies
to go to sender and all recipients, but to get only one copy of the
message, I can set "reply-to: ietf-822(_at_)imc(_dot_)org,
djb(_at_)koobera(_dot_)math(_dot_)uic(_dot_)edu"
The recipient of the message can of course override my defaults.
Some, perhaps most, UAs will not do what I intend: e.g. if the recipient
uses "reply to sender" they will send the reply to the reply-to
address, but if the recipient uses "reply to all" they will send
the reply to reply-to+to[+cc]. In which case I'll get a duplicate.
Followup-to won't fix this: for the forseeable future UAs won't
either recognize it or generate it. By the time UAs do recognize it,
lists will mung it. If the followup-to field is somehow specified
so that lists don't mung it, lists will want their own header that
specifies how to send mail to the list (further increasing the
complexity of UAs' reply operations).
If, on the other hand, his MUA supports a followup field, subscribers
suddenly have the ability to eliminate those duplicates.
But the followup-to field would also be used in other ways, just
as reply-to has been used in other ways. It would increase the
degree of variation in UA behavior and thereby increase user
confusion and tech support costs. If anything, it seems like
we have plenty of experience with reply-to that indicates that
yet another header to "control" where replies go is a Bad Idea.
Once the followup field is universally supported, the motivation for
reply-to munging will be gone.
There's a lot more motivation for reply-to munging than duplicate
suppression. Some lists want to keep discussion on the list.
Some lists want to keep discussion off of the list.
Some lists are built with the assumption that recipient's UAs
are broken and can't reply to To or Cc addreses. (If these UAs
aren't yet fixed to allow replies to To/Cc, how likely is it that
they will be "fixed" to support followup-to?) Many lists are set
up to mung reply-to based on the false assumption that "lists are
supposed to work this way", proabably because of experience with
LISTSERV and listproc and other header-munging list software.
(LISTSERV was originally written for BITNET where almost none
of the UAs in use could reply to other than a single address).
Once you have defined the new feature, convince people that the new feature
is worth implementing and supporting. *Then* worry about what to call
the header field.
Is there anyone other than Keith who's confused about the function and
benefits of a followup field?
I freely admit that I'm confused about what exists in your mind.
Most people can argue with some flexibility: by clearly communicating
their ideas, tolerating some difference in definitions from one
person to another, using intuition to guess what someone else means
in the absence of precise specification, and not assuming that others
will uniformly adopt their world-view. You don't seem to be capable
of any of these. Consequently, the only reason to discuss things
with you at all is for damage control -- to demonstrate to others
that your ideas aren't well formed. Which is not to say that you
never have good ideas, but you are apparently incapable of adapting
your ideas to accomodate others' experience. The surest way
to destroy a potentially useful suggestion is for you to argue about it,
because you'll exhaust anyone who tries to modify it based on their
own experience.
Your tendency to name calling, misstating others positions,
reiterating positions that have been modified, diverting
from the original argument and finding something else to attack
when you start to lose, "wife beating" attacks, and non sequitors
and other lapses of logic, do not lend credibility to your
arguments.
Keith