On Thu May 26 2005 19:27, Paul Jakma wrote:
I think by looking at what MUAs do, one could define that context.
Depending on what you look at, you may get a different impression
(a corollary to "if the only tool that you have is a hammer, everything
looks like a nail").
The fact that already several MUAs (popular ones at that,
thunderbird, apple mail, and mutt) /do/ do see fit to provide a "list
context"
I see nothing resembling that in Thunderbird.
And it /does/ for mutt.
Only if everybody uses that specific UA with its non-standard quirks.
Not very realistic.
"list context reply" should /not/ consider Reply-To, for if it did,
that would imply it should also consider "From", which obviously isnt
the idea.
I don't see how you're making the leap to that conclusion; From and
Reply-To fields have very different semantics -- they are not directly
linked.
However, see above, I do not (at the moment) think it would be right
to consider From/Reply-To in a "list reply" context.
I see that you said so, but you offered no rationale.
Hence, Reply-To can /not/ be used.
You're going to have to justify that claim.
For reasons you gave previously
(what exactly does it indicate?
It indicates exactly what RFC 2822 says it indicates, as previously quoted.
[...]
I suspect though I would fail if I instead set out to persuade
everyone to switch to Pine.
As long as standard mechanisms are used, and implementations comply with
those standard mechanisms, it doesn't matter which standards-conforming
implementation is used.
I'd first have to see a definition of that "list context" that is
somehow distinctive from any other "context" and which makes some
sort of sense given the fact that -- no matter what -- a respondent
is going to have to decide where he wants to send responses.
Or rather than "where", in what /context/ they wish to respond.
Choosing the /context/ is easy for an user.
Those contexts are, in every MUA I know of, 'personal', 'all' and, in
several of the more popular MUAs, 'list':
- personal
Typically (it seems to me):
To: (Reply-To) ? Reply-To : From
No, you're conflating separate things; use of Reply-To means "where the author
suggested" whereas use of From means "directly to the author(s)".
[...]
My concern is solely with the 'list' case. I would propose it be (and
apologies again for not yet being familiar with the /correct/
language for expressing these things):
- list
To: List-Post
Several problems:
1. RFC 2369 fields are not mandatory; many lists do not use them
2. Sometimes one list's expansion feeds another list, and one may
then have multiple sets of List-fields; one cannot in general tell
which list is included in another. Sending to all directly will
result in duplicates in the included list. Picking only the included
list (by guessing) won't copy the subscribers of the other list who
are not also subscribed to the included list.
The more serious problem is that mail doesn't have any notion of "context"
(other than the optional RFC 3458 field, which is unrelated to your concept);
it has only "recipients". Your list of proposed "contexts" ignores the
type of real considerations that apply to selecting recipients:
o the author(s)
o the sender
o the reverse (delivery notification) path
o where the author suggested
o other recipients of the original, as indicated by the author(s) [N.B.
there is no guarantee that they in fact were recipients]
For example, sending a "vacation"-like response is independent of any
of the items you listed as "context"; such responses need to go to the
delivery notification path (see RFC 3834).
As another, not uncommon, example, consider a message posted to a mailing
list with a request by the author to send off-list (only) responses, to
be summarized by the author. The author could easily indicate that with
Reply-To, and every response that is directed "where the author suggested"
will comply with that. For such a mailing list message, your "list context"
would send a doubly wrong response -- it wouldn't go directly to the author
(as requested) and would go to the entire list (contrary to the request).