On Tue October 19 2004 14:17, Hector Santos wrote:
----- Original Message -----
From: "Bruce Lilly" <blilly(_at_)erols(_dot_)com>
Again, the concept of a "default" is an rMUA issue, not a
characteristic of a Reply-To field.
I disagree. From a technical standpoint, this is a sound definition of
a default reply address.
You can disagree all you like, but you need a valid basis for
such disagreement. The semantics of the Reply-To field are
well-defined, and have been for a quarter century; the definition
of the field certainly does not include anything about "default
reply address". Claiming that something is a definition when it
clearly is not is simply wrong.
Again, we need to take into again the the 1:1 vs 1:many concept we
are dealing with here. The MUA is not "designed" to handle this concept
of how the original intention of the message list "holder" is distributing
the mail.
You keep repeating the same mantra; repeating it does not
make it true. Many MUAs work fine with authors who are
composing messages to be sent to mailing lists; if a particular
MUA does not, that is an issue with that particular MUA
implementation. Mailing lists didn't just pop into existence
the middle of last week; they have been around longer than
some of the core email protocols, and MUA authors have had
ample opportunity to consider the long-standing provisions
in the message protocols for dealing with list expansion -- some
have done well at it; just because some few MUA authors
have done a miserable job is no reason to dismantle the long-
standing message format. What makes you think that MUA
authors who have done a miserable job up to the present
will suddenly get things right if the message format is
changed?
like a Newsgroup Reader
where the default is a "reply to group" and the "reply to sender" is a
secondary
option.
Newsgroups and mailboxes are different entities; *of course* there
is a difference at some protocol levels between posting to a
newsgroup and mailing to a mailbox (however, as the basic
message format has been the same since RFC 850 (two decades),
and as there are gateways between news and mail, there are
also a great many situations where it is not possible to make
a distinction). A UA performs a specific set of functions; among
them is acting as an intermediary between an author and separate
transport agents. A message can be posted to a newsgroup
(e.g. via NNTP) or mailed to a mailbox (e.g. via SMTP), but it cannot
be posted to a newsgroup (directly) with SMTP or mailed to a
specific set of mailboxes via NNTP; *of course* the author needs to
indicate to a UA which method of transport is desired! Perhaps
somewhere there is some newsreader which operates as you describe
"the default is...", but the ones that I have used generally have
separate but equal functionality for posting to newsgroups, mailing
to originators, and -- additionally since you neglected to mention
it -- doing both.
One rather obvious way would be to present multiple choices
equally (and correctly labeled) rather than a default (with or
without other alternatives which are less accessible).
Ok, but why? Most MUA designers would prefer to a have a "concise"
offering to the user
There is no reason why multiple choices cannot be a concise set
of choices; I specifically mentioned a particular UA which provides
three choices in its default configuration.
for that the intentions of the backend is.
Be wary of assumptions of a particular architecture.
If the user
wants to go offline, those are secondary options.
Offline vs. online is irrelevant to the discussion. It doesn't
matter whether messages are sent (or received) immediately
or queued.
Options are always to have, but when it comes to a default, the user should
be presented with a clearly understanding of how to response to a list.
You are assuming that users can always identify whether a list is
involved; that is clearly incorrect, and any conclusions drawn from
premises including that incorrect assumption are suspect.
You can't saying the backend has nothing to do with it. I disagree.
You haven't clearly defined what you mean by "backend".
A list server can fix the reply-to address to the
list address once it takes responsibility for the new distribution as a
"List User" entity.
The issue with this?
It doesn't need to be fixed; it's not broken -- Reply-To is set by the
author. Indeed, any list expander that overwrites the author's
explicit setting of the Reply-To field is broken; it prevents the author's
specific recommendation from being communicated to his recipients
and misrepresents something as coming from the author when it has
been produced elsewhere -- it is censorship combined with forgery.
For the legacy MUA, the secondary option to "reply direct" is no longer an
easy option.
That may be so for a *particular* MUA, but it is not true in
general. There are *many* MUAs which have separate capability
of addressing a response to the author(s) of an original message
as an alternative to using the Reply-To field recommendation.