On Jul 10, 3:24am, Jamie Zawinski wrote:
} Subject: Re: best name for followups?
}
} Bart Schaefer wrote:
} >
} > The fundamental problem is NOT the behavior of reply-to-all. The
} > *really* fundamental problem is that reply-to-all is the wrong
} > function to be using in the first place.
}
} My MUA has two commands, "Reply to author" and "Reply to all".
} The former sends to (Reply-To -or- From) and the latter sends to
} ((Reply-To -or- From) -and- To -and- CC).
}
} I think this is the universally implemented status quo. I gather
} that Bart thinks this is wrong behavior, but this is that this is
} what -every- MUA I've ever seen does.
No, I don't think this is wrong behavior. I think this is right.
What I think is wrong, is that reply-to-all is (a) the "most convenient"
reply action in many UAs, and (b) necessary in too many circumstances,
because of those headed for that special circle in hell you mentioned.
} And I really wish, given the vast installed base, the standard
} spelled this out.
I agree with that, too.
} > } I'm talking about convenient _default_ recipient lists. The user is
} > } of course free to send mail wherever he wants.
} >
} > I'm talking about convenient default recipient lists, too. The basic
} > reply command ought to be where one gets those convenient defaults.
} > Reply-to-all ought to be the way the user sends mail wherever he wants
} > (e.g., find all the possible addresses for me, and let me edit some of
} > them out).
}
} Uh, I think now you're talking about a disjoint set of commands:
} "Reply to convenient default recipients" and "Reply to all listed
} addresses". I gather that you think the former list of addresses
} would be determined by some as-yet-unstandardized-or-otherwise-
} agreed-upon mechanism, and the latter would be something like
} (From + Reply-To + To + CC.)
In a world without mailing lists munging Reply-To, the former would be
controlled by the originator with a header like
From: <real-author>
Reply-To: <default-recipients>
To: <destinations>
And you'd get it when you invoke "reply-to-author". The latter would be
reply-to-all as it is now, regardless of what the headers look like.
I believe this is the correct behavior, and that the right solution is
to bypass Reply-To munging in the simplest possible manner. I think the
simplest manner is to add a new header that augments Reply-To, rather
than adding a header that restricts reply-to-all.
} [...] this would result in a confusing change to every
} existing MUA: there would still be two reply commands, but they'd be
} totally different ones than before; or worse, there'd be four distinct
} reply commands. Ugh!
No, I don't want the "new" commands to be totally different. I want them
to be as nearly identical as possible to the current status quo. In the
absence of the field that augments Reply-To, I want them to BE the status
quo.
} > Replies to address-list Y to follow up (case 2):
} >
} > From: <real-author>
} > Reply-To: Y
} > To: <destinations>
}
} In that second case, this message has destroyed my ability to reply to
} just the author -- because every MUA in existence today has a command
} that replies to (Reply-To or From), and a command that replies to
} ((Reply-To -or- From) -and- To -and- CC), but no command that even gives
} me the *opportunity* to reply to From (if Reply-To is present.)
Actually, both Mush and Z-Mail will let you ignore the Reply-To header if
you feel like it. They'll let you reply to the Dogs-Go-To-Heaven header
if you tell them to.
} Perhaps this is what the author of that hypothetical message intended.
} But if so, the author is a doofus.
You can call him names if you want, but that's the way RFC822 defines the
mechanism for authors to control where replies go. To bad mailing lists
made it insufficient.
} > The second thing required is that user agents interpret Reply-To in
} > such a way that *neither* `reply' nor `reply-using-destination-fields'
} > takes any addresses from the To field in the event that Reply-To is
} > present.
}
} That is already the status quo. Right? (For all four of the possible
} reply commands that have been mentioned, or at least, the two (possibly
} three) of them that have ever been implemented in the real world.)
No, it's not the status quo. It's the status quo for `reply'. It is not
the status quo for `reply-to-all'. The above describes the status quo
for `reply', but (Reply-To -or- (From -and- To -and- CC)) for reply-all.
(It describes that because I'm explaining Keith's proposal, which you got
right a bit later.)
} A: (Reply-To -or- (From -and- To -and- CC))
} B: ((Reply-to -or- From) -and- To -and- CC).
}
} My reading of RFC 822 (and, I gather, Bart's reading?) is that it does
} not favor one over the other, as it talks only about the "reply to
} author" command, and not the "reply to all recipients" command, which it
} relegates to the status of "extension."
Yup, that's my reading.
} Even if 822 *did* say that B was preferred to A, well, that's just too
} darned bad, because A got implemented and B did not [...]
}
} Any attempt to address either "duplicate suppression" or "default
} addresses for wide and narrow replies" (which are two totally different
} problems that people have been (badly) attempting to address using the
} Reply-To header) has to take this status quo into account if it hopes to
} get anywhere at all.
I completely agree.
--
Bart Schaefer Brass Lantern Enterprises
http://www.well.com/user/barts http://www.brasslantern.com