ietf-822
[Top] [All Lists]

Re: Understanding response protocols

2004-09-16 08:51:58

Keith Moore wrote:
And FWIW, I'm in agreement with the view that Reply-To is too messed up
to be salvaged.

(once again) What are the specific issues that you have in mind?


The way Reply-To is implemented, it is rarely useful and the behavior can 
be confusing to repliers.

For clarity, I believe that you mean the way that the behavior
of UAs w.r.t. the Reply-To field is implemented; otherwise it's
difficult to envision what you mean by the "implementation" of the
Reply-To field.

As is usually the case, it pays to differentiate implementation
issues from architectural issues.  You have stated that some UAs
fail to display Reply-To and that that can be a source of
confusion for the users (victims?) of such UAs. That is clearly
an implementation issue, one that should be addressed by the
authors of such UAs.

But the marginally useful behavior is very
widely deployed, and there are a few circumstances where it is useful.

We might disagree about "marginally"...

Changing how reply-to works probably wouldn't work very well because

Again when you speak of "how reply-to works", I believe that
you are discussing UA implementation issues.  To the extent that
some fail to display the field, changing that behavior of the
implementation would be an improvement.  Use of the Reply-To
address list as a middle (neither "narrow" nor "wide") set of
recipients for responses doesn't seem to be any sort of change,
at least for UAs that I am familiar with (given that some do
have some sort of additional "narrow" and/or "wide" types of
response functionality, and in this paragraph I'm not discussing
how the Reply-To field is used for those).

(a) there's no way to determine the sender's intent (did he want the 
old behavior or the new behavior?)

Regarding a default set of response recipients (as discussed above),
I see no "old" vs. "new" dichotomy; it's the same behavior (which
in any case is the respondent's (or his UA's) behavior). If the
original author(s) feel(s) that expressing an intent is important,
there are several ways at his.their disposal (as mentioned in a
message to this list yesterday) to so indicate (i.e. "no way to
determine..." isn't quite accurate, regardless of whether there
is any "old" vs. "new").  You have stated (and I agree) that the
respondent's desires w.r.t. responses trump those of the author,
so it is in fact the respondent's interpretation (in the absence
of any sender indication, or where there is disagreement) that
matters.  The authors' intent is at best a recommendation.

(b) it would make the effect of setting reply-to even less predictable
than it is now

Specifically for "middle" responses, I see no change. For
"narrow" responses, the From field is usually appropriate; in
some specific instances the Sender field or the envelope address
or some other address (e.g. list maintainer) may be appropriate --
it depends on the respondent's purpose.  There may well be an
issue for "wide" responses (see below), but the recipient list
for such responses will almost always require some editing.

(c) it would break behavior that is occasionally useful (e.g.,
setting reply-to on a message with one recipient is unambiguous).

And exactly what "would break"? A "middle" response still
goes to where Reply-To points (or From if there is no Reply-To
field), and a "narrow" response to From mailbox(es) would be
unaffected.

Use of From (ignoring Reply-To when present), as you have
suggested is a change to the standard response protocols.


I've suggested lots of things.  I haven't seen any suggestion, by me or
anybody else, that doesn't have some drawbacks.

True, but as mentioned yesterday, this particular change has
a rather small scope of impact; it affects only a subset of
UAs, has no impact on MTAs, etc.

The sole changes are (1) added support for narrow
responses to the From field mailboxes for UAs which do not
already have such a mechanism, 


Except that (a) we'd still like to have ways for an author to recommend
that replies go elsewhere (i.e. a way that actually makes sense when the
replier chooses "reply all") and (b) lots of people would like to have 
a simple way of minimizing duplicate copies of replies.

For (b), as I've said, I think you were on the right track when
you stated that that should be handled in the message store. For
several reasons, including the fact that some responses may be
sent some considerable time after the original message (e.g.
notification to an RFC author of a potential erratum -- there
are uncorrected typos in RFC 724 (27 years!), for example), and
as noted yesterday, mailing list subscriptions can change at a
relatively quick pace.  For "wide" responses ("reply-all"), some
editing is likely going to be required by the respondent based
on why he is responding (see below) -- there is unlikely to be
a "one-size-fits-all" solution for "wide" responses.

and (2) wide responses
possibly including From even when Reply-To is present.


that's just nuts.

Oh! Have you never sent a response to the mailbox in the From
field as well as the Reply-To address(es) when Reply-To was
present?

if reply-to is present, the sender almost certainly
intended it to substitute for from, since that's how it almost universally
works these days.   replying to both is completely wrong.

Consider the following scenario:

  From: A
  To: B, C, D
  Reply-To: C
  Date: Tue, 14 Sep 2004 12:34:56 -0700

  I'm delegating handling of the widget project to C. Deadline
  is next Thursday.

where A is delegating some action to one of the recipients, with
the intent of having any responses go to C rather than to A (in
the From field).

  From: B
  To: A
  Cc: C, D
  Date: Tue, 14 Sep 2004 12:35:15 -0700

  There may be a problem; C started his two-week vacation on
  Monday, so he won't be back until the week after next. What
  should we do?

Clearly it would be rather pointless for B to respond only to
C.  The Cc to C is so that C can see that the matter has been
addressed (when he checks his email on his return, or if he
checks it while on vacation). The copy to D also informs D of
the issue and may spare A receiving another message notifying
him of C's absence.

So it is not "completely wrong" -- what is appropriate depends
on the respondent's reason for responding.  If neither the
original author-specified recommendation (the "middle" response
recipient set) nor a "narrow" response is appropriate for the
respondent's purpose. he is left with some sort of "wide"
response (which would probably have to be hand-edited) or some
sort of hand-crafted recipient list.  In the case of an edited
"wide" response list, it is generally easier and less error-prone
to delete unwanted elements from a list than it is to manually
re-enter elements which may have been omitted; therefore it is
somewhat better in principle to hand the user a complete list
for editing than to force him to cut&paste or re-keyboard etc.

In the specific scenario above -- and yes, that sort of thing
does happen -- I'm not aware of any UAs that provide a specific
function to address a response as indicated. However, in most
existing UAs it could be generated either from a "narrow"
response with added Ccs or from a "wide" response with some
cutting and pasting (or exchanging some Ccs and Tos).  Which
brings us back to the point about the respondent's purpose -- a
UA can provide a small set of canned mechanisms to cover common
cases such as "middle" responses and "narrow" responses to the
author(s), but because it is not practical to anticipate all
things a respondent might wish to do, it is not practical to
provide for all such things; at best a UA can provide a "blanket"
"wide" response recipient set and make it reasonably convenient
for a respondent to edit that set according to his purpose, in
addition to the small set of canned mechanisms.