Keith Moore <moore(_at_)cs(_dot_)utk(_dot_)edu> writes:
NR has no way to specify situations where "reply to all" is not sent
to a superset of the recipients who would be sent if "reply to author"
were used instead.
Then NR is broken.
Or alternately: NR may not solve the problem you want to solve.
Right. I hadn't realize NR didn't solve this problem, but now I have
to say that if this mode isn't supported, I believe the benefits of NR
will be marginal compared to the cost of introducing it.
Especially considering that people will have to continue use MFT, or
standardize another header to do the same, to get a behavior they
want.
I believe NR need to address this.
Depending on how you look at it, NR and MRT are both broken (for
different reasons), and the absence of some solution(s) to several
problems associated with replies is also broken. The question is
whether, and how, we can get to a significantly less broken state with a
minimum of pain.
At this point, perhaps it is useful to enumerate requirements on the
solutions. After doing so, it is easier to evaluate which solutions
are less broken, or alternatively: solve the problems people want
solved. Two requirement:
1. Exclude the originator from being added to To/Cc on followups to
mailing lists, but keeping reply functionality from working.
2. Being able to include recipients on a copy, like BCC, but that
their names are shown in the message (and displayed by receiving
MUA), without those recipients receive further copies of the
discussion. (NR)
I know that (1) is a real world requirement, and I believe it has been
the driving reason for MFT deployment. I'm not so sure about 2, but
NR advocate for this scenario (unless I misunderstand it).
We have three approach that are specified, although not all in IETF
drafts: MFT (deployed), NR, and Mail-Copies-To (MCT), the latter is
used for news, but (at least) Gnus adhere to it in mail too, giving
similar functionality. An evaluation:
NR MFT MCT
1: No Yes[1] Yes[1]
2: Yes No[2] No[2]
Regarding [1]:
MFT achieve [1] by specifying _exactly_ where follow ups should go,
for example:
Mail-Followup-To: ietf(_at_)ietf(_dot_)org
where MCT would achieve this indirectly, by:
Mail-Copies-To: nobody
The latter would survive a rename of ietf(_at_)ietf(_dot_)org to
nobody(_at_)ietf(_dot_)org,
without the need for users to modify their MFT configurations, which I
see as an advantage. It would also survive gate:ing between news and
mail, and still make sense.
Regarding [2]:
It must be remembered that it is always possible to do:
Bcc: someone(_at_)somewhere(_dot_)example
and state this inside the message:
Note! I've sent someone(_at_)somewhere(_dot_)example a copy of this e-mail.
When would this be insufficient? I can think of two reasons.
First, internationalization. If not all recipients understand the
same set of languages. Mail can be used to transfer other things than
text, after all, so mail should be useful when there is no shared
writing system.
Secondly, it would be insufficient when we'd want programs to act on
the information. No MUA would be able to display
someone(_at_)somewhere(_dot_)org in the To/Cc line, with some different markup.
Nor would any script be able to extract someone(_at_)somewhere(_dot_)org as a
recipient of the original message, useful for e.g. message
cancellation.
When I send a message to ietf-822(_at_)imc(_dot_)org, I do _not_
want followups to be sent to the original reply address.
Note that even without either MFT or NR, you're free to set Reply-To to
ietf-822(_at_)imc(_dot_)org(_dot_) If the recipient really wants to reply to
just the
author, he can always manually override the To field of the reply. (and
if he can't do that, his MUA is broken :) That's no different than many
other valid uses of Reply-To: e.g. when someone sends a message and
wants normal replies to go to his secretary, but a particular recipient
of that message really does need to send a reply to the message author.
The difference is the amount of work requirement, and the annoyance
that result when the manual work is not been done.
MFT is widely adopted in some groups because of this, and I believe
any solution in this area should address those needs.
Thanks,
Simon