Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA (07/13/85)
RFC822 says that the REPLY-TO field can be used in three different ways: (a) Author wants his return mail to some other mailbox somewhere (b) Author may want additional people to get replies (c) Replies should be sent to a distribution list The problem with this is that many mail systems have two commands for writing replies. The name of these commands are different in different mail systems, I will here call them "personal reply" and "group reply". A "personal reply" is only sent to the author of a message, a "group reply" is sent to a group of people, usually all the recipients of the commented message. Now, the first of the three uses of the REPLY-TO field given above corresponds to "personal reply" while the other two corresponds to "group reply". Thus, a mail system implementing both the "personal reply" and the "group reply" command will find it difficult to know whether the reply-to field is of type (a), (b) or (c). I have got complaints from some people that COM consistently produces REPLY-TO fields of type (b) and (c). The complainers have mail systems, which apparently interprets the REPLY-TO field to always be of type (a), and thus use this in their "personal reply" command. However, I have strong reasons in COM for using the REPLY-TO field in the (b) and (c) sense. The reason for this is that I want to distinguish between the case when the author is a member of a conference to which the message is sent and not. When the author is a member of such a conference, replies should NOT be sent personally to the author, but rather to the conference. But if the author is not a member of the conference, replies should be sent both to the author and the conference. (The same principle, of course, would apply to mailing lists.) COM indicates this by including the author in the REPLY-TO field if he is not a member of any conference also receiving the message, but otherwise not including the author in the REPLY-TO field. Is this wrong?
wales@UCLA-LOCUS.ARPA (Rich Wales) (07/13/85)
Jacob -- I believe that the three "typical uses" of REPLY-TO spelled out in RFC822 (Section 4.4.3, page 22) are intended as three different motiva- tions for using the feature -- NOT three different possible semantics. My understanding of the semantics of the REPLY-TO field is that, if it is present, it is to be used as a substitute for the FROM field when composing replies to the message. That is, if a REPLY-TO field exists in a header, an automatic "reply" operation should ignore the FROM field completely, under all circumstances, and use the REPLY-TO data instead. If the sender of the message needs to use a REPLY-TO field, but also wants to be one of the recipients of any reply, he must include his own address in the REPLY-TO field along with the addresses of the other intended recipients. I am not 100% sure I understood your description of the criteria used by COM in deciding whether to include the sender in the REPLY-TO field, so I am not sure whether COM uses REPLY-TO correctly or not. If you would like to try again to explain what COM does with REPLY-TO, I will gladly try to help you figure out whether its use of REPLY-TO follows the RFC822 semantics, and if it doesn't, whether there is some alternative approach that would do what you want. -- Rich
don.provan@CMU-CS-A.ARPA (07/13/85)
One problem here is that there are really three types of replies: the personal and group replies you mentioned, and then a third one that might be called a message directed reply or a default reply or a normal reply. The first sends the reply to the person who sent the message, so I'd be tempted to use the From: field for that, although I believe the From: field need not be legal if there's a Reply-to: field. The second sends the reply to everyone who saw the original message. The third sends the reply to anyone the sender thought should see a reply. The Reply-To: field was provided for this use. So my feeling is that the people with the "personal reply" command are trying to do something that isn't supported by the protocol. If it's supported at all, they should be replying to the From: field, not the Reply-To: field.
stef@uci-icsa.ARPA (Einar Stefferud) (07/15/85)
Rich Wales has it right! REPLY-TO is a replacement for FROM (and SENDER), if REPLY-TO exists, and then "personal reply" should use whatever is in REPLY-TO "as requested by the originator", no matter what REPLY-TO contains. Jacob's use to direct replies to whomever he (as the conference chair) wants replies to go to is technically correct, though perhaps he may be overusing it. But this is a social question of good chairmanship. I would tend to be less demanding of recipients who might very well want to make personal replies, and find themselves either thwarted, or bothered by the need to manually edit the address fields of a reply to achieve their desires. However, at times I like to force replies to a whole group by putting the groupname in a REPLY-TO field. I think it is customary in the Internet for recipients who want to reply to all addressees to not use the "personal reply" form of the reply command, and thus they will reply to the whole collection of REPLY-TO/FROM/SENDER, TO, and CC addressees. However, I know a number people who frustrate me continually by (unconciously?) omitting other addreessees, which forces me to manually relay to them when I am trying to promote a group discussion. I wish they would cooperate more. In a way, Jacob's use suggests that he may not trust recipients to use the "group reply" when they should. If a Conference Chair does not trust recipients, then it may be correct to force the issue on them. If the Chair does trust them, then they should really be trusted, by not forcing the issue with such intractable REPLY-TO fields. Please do not take these comments as personally directed. As I see it, we are caught among varying semantic interpretations and social customs, and it will take us a while to get things sorted out. Jacob is trying to cope with a blend of Structured Conference services and Unstructured Internet Mail services to conduct conferences. I don't know anyone else who is even trying this, so I am interested in helping Jacob to understand the Internet side of things (even if I have to shout from time). We really do need to be able to accomodate COM type User Agents in our growing Mail Internet. The trick is to get them to behave in concert with other practices in other contexts. Peace - Stef
Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA (07/15/85)
> FROM: Rich Wales <wales@UCLA-LOCUS.ARPA> > My understanding of the semantics of the REPLY-TO field is that, if it > is present, it is to be used as a substitute for the FROM field when > composing replies to the message. A message system which has two reply commands, called "personal reply" and "group reply", would for a message without any REPLY-TO field use the "FROM" field when the "personal reply" is used, and would perhaps combine the "FROM", "TO", "CC" and "SENDER" fields when the "group reply" command is used. Thus if, as you say, the "REPLY-TO" field is to be used as a replacement for the "FROM" field, this seems to indicate that maybe the "REPLY-TO" field is mostly to be used for "personal reply" commands. However, the text in RFC822, which says that "REPLY-TO" can be used when you want answers to be sent to a group, seems to indicate that the "REPLY-TO" field is to be used also for "group reply" uses. > FROM: Rich Wales <wales@UCLA-LOCUS.ARPA> > I am not 100% sure I understood your description of the criteria used by > COM in deciding whether to include the sender in the REPLY-TO field. An example: Suppose we have a mailing list called III@JJJ with three members: - AAA@BBB - CCC@DDD - EEE@FFF Suppose a message written by GGG@HHH, who is not a member of the list, is sent to this mailing list. Then I would make the following REPLY-TO clause: REPLY-TO: III@JJJ, GGG@HHH This would ensure that GGG@HHH would get the replies, even though GGG@HHH is not a member of the list. If however, AAA@BBB sends a message to the list, I would create the following REPLY-TO clause: REPLY-TO: III@JJJ AAA@BBB would *not* be included in the REPLY-TO clause, since AAA@BBB is a member of the mailing list, and will receive the message via the list. If in this case AAA@BBB was included in the REPLY-TO clause, AAA@BBB might get two copies of the replies, one directly and one via the list (an intelligent system might be able to merge the two copies before displaying them to the user, but still the two copies would increase transmission cost and would confuse COM, since COM would not know whether to regard it as a personal message or a mailing list message - COM allows users to give different priority to incoming messages belonging to different mailing lists.
wales@UCLA-LOCUS.ARPA (Rich Wales) (07/15/85)
Jacob --
I thought of another way of describing the RFC822 semantics of REPLY-TO
last night, after I sent my reply to your original message. It may seem
a bit backwards at first, but I think it makes the situation somewhat
clearer than the traditional perspective.
(1) Think of *every* message as *always* having a REPLY-TO field -- at
least conceptually.
Consider that RFC822 has provided a short-cut in the interests of
brevity and non-redundancy in message headers. Namely, if the
"Reply-to:" header line contents are identical to the "From:" line
contents, then the "Reply-to:" line can be (and probably will be)
omitted from the header when the message is sent. The receiving
end, on finding that a message has no "Reply-to:" line in its
header, will implicitly create a REPLY-TO field by copying the FROM
field.
If you assume in this way that *all* messages have REPLY-TO fields,
the rules for constructing the recipient lists for replies suddenly
become much simpler and more straightforward.
(2) Automatic replies *always* go to the addresses in the REPLY-TO field
(which, by the above assumption, always exists in every message).
The FROM field is *never* considered when addressing a reply. To be
sure, the REPLY-TO field may have been implicitly derived from the
FROM field when the message was originally read and the header was
parsed -- but once this operation has been done, we simply concen-
trate on the fact that the message has a REPLY-TO field, forgetting
completely about where it came from.
(3) You can then distinguish, if you wish to, between "personal" and
"group" replies in the following way:
(a) "Personal" replies would go only to the address(es) in the
REPLY-TO field.
(b) "Group" replies would go to the address(es) in the REPLY-TO, TO,
and CC fields.
It is debatable, by the way, whether a "group" reply should also
go to the SENDER address(es); Section 4.4.4 (page 22) of RFC822
states that the SENDER field should never be used automatically
when replying to a message. I would suggest that the SENDER
field be included in the address list of a "group" reply only
through invocation of a non-default option, if indeed at all.
You expressed some confusion/concern over whether RFC822's semantics of
the REPLY-TO field envision the use of this field in "personal" replies
or in "group" replies. I think what happened was that RFC822 assumed
that the message *author* -- *not* the recipient -- would make the deci-
sion as to who would receive replies.
At the time (and probably even now), most people were accustomed to mail
systems where the only kind of reply was what you term a "personal"
reply (i.e., to the author of the message and no one else). The REPLY-
TO field was apparently envisioned as a way to allow the message sender
to specify a wider audience for any replies to his message, without
having to assume that the person at the other end had a mail system
capable of automatically constructing a "group" reply (since most people
didn't have such mail systems anyway).
Hence, RFC822 does not really seem to provide for the kind of distinc-
tion between "personal" and "group" replies which you would like to
make. Clearly, the issues involved were not fully appreciated, and had
not been thoroughly thought out, when the standard was written. My
making this observation is not so much an indictment of the people
responsible for RFC822 (who, I think, did a very good job considering
the constraints they were working under) as it is a realization that
our understanding of the possibilities of electronic mail has kept on
expanding.
I think this is a good occasion to renew my suggestion that some person
or group should investigate issues such as these, and make sure that the
various kinds of recipient lists (personal replies, group replies, con-
ferences, etc.) can be adequately represented in X.400 or other appro-
priate international standards.
--
Rich Wales // UCLA Computer Science Department // +1 213-825-5683
3531 Boelter Hall // Los Angeles, California 90024 // USA
ARPA: wales@UCLA-LOCUS.ARPA -or- wales@LOCUS.UCLA.EDU
UUCP: ...!(ihnp4,ucbvax)!ucla-cs!walesJacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA (07/17/85)
The solution proposed by kre@ucb-vax.arpa is neat, but I am not sure that it will work. Many mailing lists distribute to sub- mailing-lists in many stages, and it will be difficult to arrange for the personal copy and the list copy to follow the same path through the hosts with the sub-lists. Another problem is that users may not always, generally, want their personal copies to be discarded if the message will reach them via a bulletin-board. In COM, where all mailing list messages are read via computer conferences, we have found it very useful to have a facility to send a message in exceptional cases both to the conference and at the same time to a personal mailbox of a member of that conference. (COM will then normally only show him the message in his mailbox, not in the conference.) The reason for this is that he may delay reading the conference if he has much to do, and our users usually read their personal mailboxes first, so this is a way of giving priority to certain conference messages to certain members of those conferences.