Message-ID: <2107E82D78C2D1118A340000F8033450BF9C@VHAISFEXC1>
From: "Woodhouse, Gregory J." <gregory.woodhouse@med.va.gov>
To: Jacob Palme <jpalme@dsv.su.se>, "'Keith Moore'" <moore@cs.utk.edu>
Cc: IETF working group on revision of mail standards <drums@cs.utk.edu>
Subject: RE: Need for multiple reply destination sets? 
Date: Tue, 24 Mar 1998 19:28:25 -0600
MIME-Version: 1.0
Content-Type: text/plain

It seems to me that users are typically conscious of at least the
following situations:

1. The user is replying to a one-on-one message; no group discussion is
involved.

2. There is a group discussion but no mailing list software is involved
and the user wants to reply either to the person sending the message or
the whole group.

3. There is a group discussion being carried out using a mailing list
and the user wants to reply either to the person sending the message or
everyone.

This is likely the result of years of training as much as anything.

On the other hand, I don't think the typical user thinks about these
kinds of situations

4. The user wants to reply to the actual sender of the message not the
person for whom they are proxy (this is the terminology of our own in
house mail product).

5. The user wants to reply to a specific address which has been
designated for use when acceptying or declining a meeting request or the
like.

I think 1-3 can be handled using the two button interface (I know, I
know..) that has become popular, though some extensions to 822 and
possibly 821 (I haven't really worked this one out yet) may be needed. I
really don't know what I think about 4, and I think 5 belongs in the
domain of calendaring and scheduling. We can't do everything.

My take on the alternatives to "Reply-To replaces only From" is that
they are too ambitious. They try and bring list behavior under the
umbrella of DRUMS which probably can't be done. I think we should
specify the semantics of Reply-To along the lines that Dave Crocker has
suggested and then undertake the development of extensions to support
group discussions (other items?) as a separate activity -- and do so
expeditiously. This functionality is very much needed!

Anyway, to repeat we can't come up with a version of 822bis that will
handle mailing lists intelligently because it can't be done. At the very
least new fields are needed. I think Keith Moore's Respond-To etc. are
an interesting approach, but my feeling is that we need a separate
standards track activity to define them.

==
Gregory Woodhouse <gregory.woodhouse@med.va.gov>
San Francisco CIO Field Office - Infrastructure
+1 415 744 6362
Permanent fixes are temporary; temporary fixes are permanent.


> ----------
> From: 	Keith Moore[SMTP:moore@cs.utk.edu]
> Sent: 	Tuesday, March 24, 1998 7:14 AM
> To: 	Jacob Palme
> Cc: 	Keith Moore; IETF working group on revision of mail standards;
> moore@cs.utk.edu
> Subject: 	Re: Need for multiple reply destination sets? 
> 
> > > I don't think so.  It adds a lot of complexity -- to the protocol,
> > > to the design of user agents, and to the recipient's decision
> > > process -- for very marginal gain.
> > 
> > I do not at all think that the gain is marginal. The gains are very
> large:
> 
> 1. How often, when composing a message, do you think to yourself:
> 
> if the recipient wants to respond for reason A, he should send to
> 	address X
> if the recipient wants to respond for reason B, he should send to
> 	address Y
> if the recipient wants to respond for reason C, he should send to
> 	address Z
> 
> ...where there are more than one of these options?  I'm not saying
> that it never happens, just that it happens so seldom that we don't
> need a special facility for it in the message header.
> 
> 2. for the cases above, how often are reasons A, B, C...
> well-defined and widely recognized roles for which a 
> machine-readable label (and semi-automatic handling by
> the recipient) might be appropriate?  How often are they
> ad hoc roles that are specific to your particular message?
> 
> Keith
>