Keith Moore wrote:
And FWIW, I'm in agreement with the view that Reply-To is too
messed up>>to be salvaged.
(once again) What are the specific issues that you have in mind?
The way Reply-To is implemented, it is rarely useful and the
behavior can be confusing to repliers.
For clarity, I believe that you mean the way that the behavior
of UAs w.r.t. the Reply-To field is implemented; otherwise it's
difficult to envision what you mean by the "implementation" of the
Reply-To field.
Yes. But the reason that Reply-To was implemented that way can be
traced to language in RFC 822 that implies that Reply-To replaces From.
As is usually the case, it pays to differentiate implementation
issues from architectural issues. You have stated that some UAs
fail to display Reply-To and that that can be a source of
confusion for the users (victims?) of such UAs. That is clearly
an implementation issue, one that should be addressed by the
authors of such UAs.
It could also be attributed to a failure in the specifications.
Changing how reply-to works probably wouldn't work very well because
Again when you speak of "how reply-to works", I believe that
you are discussing UA implementation issues.
Yes, but any changes to such behavior, if they were to take place, would
probably need to be prompted by new specifications or changes to
existing specifications.
To the extent that
some fail to display the field, changing that behavior of the
implementation would be an improvement.
Failure to display the field is only one of several problems with
the way Reply-To is handled today.
Use of the Reply-To
address list as a middle (neither "narrow" nor "wide") set of
recipients for responses doesn't seem to be any sort of change,
If it became widespread, that would certainly be a departure from
existing practice. However I don't think that widespread
implementation of "middle" reply would be a step in a useful direction.
(a) there's no way to determine the sender's intent (did he want the
old behavior or the new behavior?)
Regarding a default set of response recipients (as discussed above),
I see no "old" vs. "new" dichotomy; it's the same behavior (which
in any case is the respondent's (or his UA's) behavior). If the
original author(s) feel(s) that expressing an intent is important,
there are several ways at his.their disposal
These exist regardless. By that argument, we don't need reply-to or
mail-followup-to or any other header field to affect how replies are
addressed.
You have stated (and I agree) that the
respondent's desires w.r.t. responses trump those of the author,
so it is in fact the respondent's interpretation (in the absence
of any sender indication, or where there is disagreement) that
matters. The authors' intent is at best a recommendation.
You're reading way too much into this. The recipient of a message
wishes to reply to the author of a message, and notices that there's
a reply-to field that points to an address he doesn't recognize.
Should the recipient reply to the From address instead, or should
he send the reply to the Reply-To address? He doesn't know, because
he doesn't know _why_ the sender set reply-to. It could be because
the sender is pointing to an alternate address for himself - say
because he wants to get replies on his PDA. Or it could be because the
sender thought replies should go to his secretary, or to a list, or
somewhere else. The recipient of the message has no idea whether it's
appropriate to send _his_ message to the reply-to address.
(b) it would make the effect of setting reply-to even less
predictable than it is now
Specifically for "middle" responses, I see no change.
We seem to be talking about two different things. I'm talking about a
new header field that would change how (new) UAs compose replies by
default. You seem to be talking about a new reply button.
Use of From (ignoring Reply-To when present), as you have
suggested is a change to the standard response protocols.
I've suggested lots of things. I haven't seen any suggestion, by me
or anybody else, that doesn't have some drawbacks.
True, but as mentioned yesterday, this particular change has
a rather small scope of impact; it affects only a subset of
UAs, has no impact on MTAs, etc.
I disagree.
The sole changes are (1) added support for narrow
responses to the From field mailboxes for UAs which do not
already have such a mechanism,
Except that (a) we'd still like to have ways for an author to
recommend that replies go elsewhere (i.e. a way that actually makes
sense when the replier chooses "reply all") and (b) lots of people
would like to have a simple way of minimizing duplicate copies of
replies.
For (b), as I've said, I think you were on the right track when
you stated that that should be handled in the message store.
My sense is that that answer doesn't sound good to lots of people.
I'm still trying to understand why. I think there are at least
two issues here. One is that it requires substantial changes to
existing message stores (if you built one from scratch to handle this it
would be fairly easy). Another is that ordinary users have much
more ability to change or upgrade their user agents than they have
to upgrade their message stores. So there may be a perception
(and it may be correct) that it's easier to deploy a solution to
this problem in the MUA than in the message store - even if,
from a purely technical perspective, it doesn't work as well as
the message store solution.
For
several reasons, including the fact that some responses may be
sent some considerable time after the original message (e.g.
notification to an RFC author of a potential erratum -- there
are uncorrected typos in RFC 724 (27 years!), for example),
Please consider the possibility that nobody cares about RFC 724
anymore - and that the RFC Editor doesn't want to fix typos in
RFCs after they are published.
and
as noted yesterday, mailing list subscriptions can change at a
relatively quick pace. For "wide" responses ("reply-all"), some
editing is likely going to be required by the respondent based
on why he is responding (see below) -- there is unlikely to be
a "one-size-fits-all" solution for "wide" responses.
and (2) wide responses
possibly including From even when Reply-To is present.
that's just nuts.
Oh! Have you never sent a response to the mailbox in the From
field as well as the Reply-To address(es) when Reply-To was
present?
Perhaps, but it's been extremely rare - and I probably only did this
when the Reply-To addresses were redundant with other addresses
that were already in the recipient list.
if reply-to is present, the sender almost certainly
intended it to substitute for from, since that's how it almost
universally works these days. replying to both is completely
wrong.
Consider the following scenario:
There are lots of scenarios that could be constructed. Which ones
deserve to have buttons dedicated to them? Note also that in the
example you gave it probably makes more sense to say "reply
ignoring Reply-to" than "reply to both From and Reply-To"
Keith