[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Understanding response protocols
On Tue October 19 2004 14:17, Hector Santos wrote:
> ----- Original Message -----
> From: "Bruce Lilly" <blilly@xxxxxxxxx>
> > 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
> like a Newsgroup Reader
> where the default is a "reply to group" and the "reply to sender" is a
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
> 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.