On Jul 9, 3:17am, D. J. Bernstein wrote:
} Subject: Re: best name for followups?
}
} > In email, using reply-to, I can manually redirect a discussion away from
} > inappropriate recipients. What's the difference?
}
} My proposal---using Reply-To to control replies, and a followup field to
} control followups---is a _labelled_ change from RFC 822 semantics.
}
} Your proposal---using From to control replies, and Reply-To to control
} followups---is an _unlabelled_ change from RFC 822 semantics.
That's not Keith's proposal, and you ought to know that it isn't. Keith's
proposal is to use Reply-To to control replies, and to ignore the concept
of followups entirely. I happen to agree with him on the latter point; I
don't think it's useful to apply the netnews concept of `followup' to the
common email UA function of `reply using From + To + Cc'. They happen to
have a similar effect if and only if one of those headers contains the
address of a mailing list, but they're still not really the same thing.
} You keep complaining that MUAs don't use From and Reply-To the way you
} suggest. That's because they're following RFC 822, section 4.4.4.
Actually, none of them are following 4.4.4 when they do `reply to all',
because 4.4.4 doesn't apply to the To and Cc fields. It applies only
to From, Sender, and Reply-To. Anything that automatically uses To and
Cc in that way is extended functionality, not covered by RFC822. There
is no mention anywhere in 822 of using To and Cc that way.
Even if you grant dispensation for common practice, it's debatable whether
they're following 4.4.4; the statement there is:
If the "Reply-To" field exists, then the reply should go to the
addresses indicated in that field and not to the address(es)
indicated in the "From" field.
It's been argued that the "and not to ..." clause is extraneous, and that
the interpretation was meant to be "... go to the addresses indicated in
that field, and nowhere else." Which is exactly what the basic `reply'
function does in all the UAs that you listed; the `reply to all' function
is ignoring the implicit "and nowhere else."
(Section 4.3.1:
The "Reply-To" field is added by the originator and serves to
direct replies, ...
Section 4.4.3:
The "Reply-To" field is added by the originator and is intended
to direct replies.
But they both muddy the issue by attaching clauses about Return-Path, so
there's no definitive "and nowhere else" anywhere.)
Furthermore, most of those UAs' `reply to all' functions behave as `reply
using (Reply-To OR From) + To + Cc'; some do even more complex things, but
in any case they're usually doing a 4.4.4 `reply' and then, in addition,
using some other set of addresses. That fits the definition of extended
functionality, I'd say.
I happen to think it's useful enough extended functionality that it ought
to be recognized by the standards; but confusing it with the concept of
`following up' is the wrong approach.
} Of course, this is only a guess at what your proposal means, since you
} consistently refuse to say what you want real MUAs to do with their two
} built-in response functions.
I won't presume to speak for him, but my understanding is that the second
response function should be `reply using Reply-To OR (From + To + Cc)'
(note the change in parenthesization). Maybe a better characterization
is that `reply' should always mean `using Reply-To OR From', and tacking
on addresses from any other source should be in a different category.
This essentially means that we don't change RFC882, but rather that we
start insisting that UAs obey the strictest possible interpretation of the
Reply-To header. I dislike that for various reasons, but I find it even
more distasteful to stir `followups' into the mix.
--
Bart Schaefer Brass Lantern Enterprises
http://www.well.com/user/barts http://www.brasslantern.com