Re: Understanding response protocols

[Bruce Lilly <blilly@xxxxxxxxx>]

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
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.