On Jul 9, 4:53pm, D. J. Bernstein wrote:
} Subject: Re: best name for followups?
}
} > * It requires UAs to restrict their reply-using-destination-fields
} > behavior when it is present,
}
} Yes, it's a change in the followup behavior. That's the whole point.
}
} > rather than permitting them to extend
} > their basic reply behavior when it is present.
}
} I don't understand. Do you have some specific change in mind?
See below.
} How does it conflict with a change in followup behavior?
It doesn't conflict; I just don't believe that a change in reply-using-
destination-fields is a good or likely thing. Even if it does change,
the change is more likely to be that it becomes `reply using From + To
+ Cc + The-New-Field', which is exactly the opposite of what you want.
Hence if you're going to add a new field, you might as well add a field
that has fits that behavior to begin with.
} Hmmm. I get the feeling that you think I'm talking about writing a spec.
} I'm not. I'm talking about changing the behavior of real MUAs. The only
} relevant people are MUA implementors.
That's a lovely idea, but if you don't write a spec the chances approach
zero of more than two different implementors agreeing on how it works.
Look at all the odd edge conditions in reply-using-destination-fields.
} > * It requires originators to supply too much information; they must
} > not only suggest how recipients should deal with their own address,
} > but must also suggest how to deal with all destination addresses.
}
} Why is this a problem? Could you give a specific example where the
} originator would have trouble coming up with the information?
The problem is not that the originator can't come up with the information.
The problem is that the responding UA can't obey both the originator's
recommendation and the responding user's instructions. The responding
UA must either ignore the destination fields even when instructed (by the
responding user) to include them, which I think is bad; or it must ignore
the originator's recommendation when asked to do a simple reply.
Skipping ahead for a bit:
} Replies are typically sent to Reply-To defaulting to From. You're saying
} that they should be sent to Reply-To+Reply-Cc defaulting to From. Right?
Right so far.
} Aside from Reply-To munging and the difference between To and Cc, your
} proposal adds no new capabilities. A user can simply merge your Reply-Cc
} into Reply-To to obtain the same results.
Essentially correct; the minor difference being that Reply-Cc goes into
the Cc field, not into To. In fact, it is exactly the intention that
there are no new capabilities *except* the ability to bypass Reply-To
munging.
} Your real proposal is the same as Keith's: you want to put the mailing
} list into Reply-To, and the sender's personal reply address into From.
} You expect MUAs to have a respond-to-From-ignoring-Reply-To function.
} Right?
Completly wrong. To address the "followup problem," I want to put the
sender's personal reply address into Reply-Cc if and only if he is not
a member of the mailing list; if he is a member of the mailing list, I
think the Reply-Cc should be left out entirely. What goes in Reply-To
is whatever goes in Reply-To right now, munged however the list server
munges it right now; I don't care.
I expect MUAs to expand the `reply' function to mean `send to (Reply-To
OR From) + Reply-Cc'. I expect `Reply-To' to continue to replace `From'
as it does now.
I further expect MUAs to expand `reply-using-destination-fields' to mean
`send to (Reply-To OR From) + Reply-Cc + To + Cc'. However, I expect
users to realize that `reply-using-destination-fields' is no longer the
right thing to use to "follow up," because `reply' does what they want.
That means I expect UAs that support Reply-Cc to stop making `reply to
all' be the most-easily-accessed reply function.
} Later you make clear that you're proposing a change purely in reply
} behavior, not in followup behavior.
It is correct that I do not propose to reduce reply-using-destination-
fields behavior in any sense.
} The followup field is the same as From+To+Cc by default. The MUA can
} automatically remove the From address if it knows that the user is on a
} mailing list shown in To+Cc. The followup field is copied into
} subsequent followups.
The Reply-Cc field is the same as From by default (simpler). The MUA
can automatically remove the entire field if it knows the user is on a
mailing list (simpler -- and the operation really is that the MUA can
ADD the field if it does NOT know whether the user is on the mailing
list, which means it works even in UAs that don't maintain that info).
The Reply-Cc address is copied into the Cc of subsequent "followups."
--
Bart Schaefer Brass Lantern Enterprises
http://www.well.com/user/barts http://www.brasslantern.com