Keith Moore wrote:
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.
I don't follow that; which part of the specification do you
believe is responsible for failure of some UAs to display the
field?
(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.
No, that's not the argument. You seem to be conflating the
recipient list with the indication of intent.
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.
Perhaps not, but he presumably knows why he wishes to respond.
While there may in fact be many reasons for an author to
suggest response addresses, there are also many reasons why a
particular recipient might respond.
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.
Perhaps he only wants responses sent to his PDA (or secretary)
for a limited period of time. Perhaps he expects different
recipients to respond to different addresses. I don't believe
it practical to devise a way to handle the myriad of
circumstances that individual authors might under some
situations like to express -- at least not without adding
more confusion to the situation (which languages should
the authors desires be expressed in, which charsets, what
formats should be used for date and time, how should
precedence relationships be expressed, etc.).
The recipient of the message has no idea whether it's
appropriate to send _his_ message to the reply-to address.
The potential respondent is going to have to think about
it, no matter what. Even if there are a thousand fields
similar to
Respond-here-on-weekdays: foo(_at_)bar(_dot_)com
Respond-here-for-urgent-matters: 911(_at_)xyz(_dot_)net
Respond-here-for-my-assistant: asst(_at_)bar(_dot_)com
etc. ad nauseum.
(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.
What do you mean by "default" -- what is the specific
respondent action that you have in mind that all respondents
are supposed to conform to?
As far as "buttons" are concerned, I'm not speaking of
any specific type of UI; many UAs already distinguish
among generic "reply", narrow "reply-to-author", and
broad "reply-to-all" functions (whether they use text
interfaces or GUI interfaces is largely irrelevant).
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.
Would you like to elaborate?
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).
As mentioned, Cyrus IMAP already has a configurable option
for this (implemented in the message store).
Another is that ordinary users have much
more ability to change or upgrade their user agents than they have
to upgrade their message stores.
That might be so for a user who uses only one UA on only
one computer to access his messages. I don't think we
should restrict our thinking to that model.
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.
Unless one is dealing with a large centralized time-sharing
system, duplicate detection (let alone suppression, for some
meaning of the term) at an MUA requires that the MUA have
access to sufficient information to perform the task. An
MUA that accesses messages by any of the likely protocols
(POP variants, IMAP) is going to involve substantial
amounts of client/server traffic. Better to handle
duplicate detection/suppression at the MDA or message
store.
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
It is certainly possible that few people are interested
in correcting errors in RFC 724 -- but that was just one
example; RFCs 2045 (7+ years) is another example.
and that the RFC Editor doesn't want to fix typos in
RFCs after they are published.
Perhaps -- but that's not what the RFC Editor's web page
says. In fact it provides an extensive set of errata.
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.
That wouldn't explain including the From field mailbox when
it was not present in To or Cc.
There are lots of scenarios that could be constructed. Which ones
deserve to have buttons dedicated to them?
If you wish to discuss UI design, a potentially more productive
approach might be to consider allowing the user to pick and
choose from among the standard address fields (From, Reply-To,
To, Cc, Sender, Return-Path) in the original message. That
would certainly provide flexibility.
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"
No, for the reason given with the example (to keep the
person at the Reply-To address advised that the situation
is being handled).