[Top] [All Lists]

Re: best name for followups?

1997-07-10 09:43:22
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

} > 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    

<Prev in Thread] Current Thread [Next in Thread>