Re: Understanding response protocols

----- Original Message -----
From: "Alan Barrett" <[email protected]>
To: "ietf-822" <[email protected]>
Sent: Tuesday, June 07, 2005 4:44 AM
Subject: Re: Understanding response protocols


> On Mon, 06 Jun 2005, Hector Santos wrote:
> > old :
> >
> > char *ReplyToSender()
> > {
> >   char *to_address = reply_to_address;
> >   if (to_address empty) to_address = from_address;
> >   return to_address;
> > }
>
> A function that does the above should be labeled "Reply" or "Reply to
> author's suggested reply address", or something similar.  A function
> labeled "Reply to sender" should reply to the "Sender:" address, or to
> the "From:" address if there is no "Sender:" address.
>

Ahh, I see the confusion.  In no way was I implying that it was a reply to
the "Sender:" address concept simply because it is not part of the MUA
methodology (MUAs do not reply to a Sender: address).  I was making the
relationship to the typical CUI, ergonomics options available, atleast as I
see it for my current MUA (OE), when I right click your message the popup
menu shows:

    Reply To Sender
    Reply To All

etc.

But I see your point. Technically, we have in our system called OOMS Object
Oriented Message System, a C/C++ virtual class object system. a virtual
method as follows:

// virtual
char *CMesageObject::GetDefaultReplyAddress()
{
    return NULL;
}

which is virtual abstract class for the many different mail formats and
networks we support.  So the virtual override for this abstract when using a
RFC 822/2822 would be something like so:

// virtual
char *CRFC2822MesageObject::GetDefaultReplyAddress()
{
   char *to_address = headers["Reply-To"];
   return to_address?to_address:headers["From"]
}

If there existed a new "List-Reply-To:" concept,  we would use (explore) a
simple update:

// virtual
char *CRFC2822MesageObject::GetDefaultReplyAddress()
{
   char *to_address = headers["List-Reply-To"];
   if (!to_address) to_address = headers["Reply-To"];
   return to_address?to_address:headers["From"]
}

But the odds are good we would use a Pull Down concept like we have in one
of our MUAs (Platinum Xpress - and online GUI Sysop Editor) where would show
all the potential reply addresses in a pull down list which the most
expected address for the action to be the default, in order words, the pull
down would appear in the following order, as made available:

    List-Reply-To:
    Reply-To:
    From:

This would be a for a normal "Reply" concept.

We currently do not do this in our web mail client for a reply. It picks the
default and allows the user to change it but that depends on the conference
type:

    Email          - open field
    Mailing List  - a fixed reply address is set by the sysop

And this is what I wanted to illustrate.  When using an Offline concept, the
backend system can not control the fields, and I am not suggested that it
does. Yet, it maybe the future for the more advanced MUA more aware or 1 to
1 EMAIL vs. 1 to MANY (List, News) concepts. That all depends on the desires
of the MUA author.  There is certainly no reason why the MUA can't enforce
it, but the offline nature also means it needs to be flexible and provide
all the possible options.

If I replied to your message via web mail,  it will go to the defined list
address simply because the conference is setup that way.  I have no control
as a user in this case via web mail.

With my offline RFC, well,  I want to reply back to the list.  Not to you.
The problem?  It all depends on who's message I am reading on the list.  For
your message, I have to click Reply to All to get the list address and
manually delete your address from the multiple addresses it grabbed.   For
Bruce's message, a simply reply will do it.  If I wasn't paying attention,
duplicate mail goes out.   Most people will prefer a consistent behavior
regarding of which list they are using.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com