To: The Esteemed Members of the DRUMS Working Group <drums@cs.utk.edu>
Subject: Re: Reply-To Proposal (Type 1) available 
In-Reply-To: Your message of "Fri, 31 Oct 1997 21:15:04 -0000."
             <3.0.32.19971031182427.008b7100@pop.dial.pipex.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sun, 02 Nov 1997 23:30:21 +1100
Message-Id: <14521.878473821@munnari.OZ.AU>
From: Robert Elz <kre@munnari.oz.au>

    Date:        Fri, 31 Oct 1997 21:15:04 +0000
    From:        Graham Klyne <GK@ACM.ORG>
    Message-ID:  <3.0.32.19971031182427.008b7100@pop.dial.pipex.com>

  | I think this interpretation is not, however, unarguable, because RFC822
  | A.2.4 does not appear to exclude sending messages to additional recipients
  | of the original message.

You misunderstood the point I was making (incidentally, that is almost 
certainly my problem, it is rare for anyone to understand what I am really
trying to say based on text I write - especially the first draft before
there's been feedback to allow the worst parts to be fixed).

The point there was that "Reply to Author" using "Reply-To" as its address
cannot be correct (just from examining RFC822).   This is regardless of
whether or not additional addresses can be added anywhere.

This all relates to that "two button" UI that is much discussed.

That is often characterised as being "Reply to Author" and "Reply to
Everyone".   There's no doubt that quite a lot of UIs implement that as
a model, or that's what they claim.  It has also been claimed that this
is the model that users desire.

What tends to be implemented though is something quite different, being
(where a Reply-To header exists), "Reply to Reply-to" and "Reply to Reply-to
and other addresses"  (it doesn't matter here what the other addresses are,
typically they're To+cc).

Now as a model, that makes no sense, because, as we are discovering, there's
no definition of what Reply-To actually means, so "Reply to Reply-To" should
really be labelled "Reply to indeterminate place" (there simply isn't agreement
as to where such replies will actually go - today that is).  What it is
not is "Reply to author".

Now that could actually be fixed by defining Reply-To of course, and that's
what we're supposed to be doing here, but anyone who wants both "replies go
to Reply-To instead of From" and "reply to author" as the way things work
has to define the reply-to address as being the address of the author(s).
But that is exactly what the From header is supposed to be - we'd end up
defining two headers with the same meaning.   That makes no sense at all.

Any other definition of Reply-To does not allow "reply to author" to use
the Reply-To header as the target address.   That may be OK, but it means
that all of those implementations and users that seem to want this 
functionality don't actually exist at the minute as has been claimed.

  RFC822 section 4.4.4 also says:
  |         This recommendation is intended  only  for  automated  use  of
  | -->     originator-fields  and is not intended to suggest that replies
  | -->     may not also be sent to other recipients of messages.   It  is
  |         up  to  the  respective  mail-handling programs to decide what
  |         additional facilities will be provided.

For what it's worth, I 100% agree with the basic sentiment of this, which
is that users must be allowed to send e-mail to any addresses they want.
Further, they have to be able to obtain install & use user agents that
make it easy for them to send to the addresses they want (ie: we cannot be in 
the business of telling user agent authors which addresses they have to make
the easy ones for the user to use, and which have to be harder in some way).

I actually think the "automated use" part of this is horribly bogus, and
I think Reply-To would vanish down sewer if anyone were actually doing that
in any significant way - automated replies go to the envelope sender address,
or for particular uses, other addresses provided (like for DSN) nothing else
is rational (automated replies are things like mail from "vacation" programs
and stuff like that).   If an RFC822 header needs to be used, it ought be
Sender if there is one, and From if there isn't.   Reply-To, as it is shown
in 822 cannot reasonably be useful for that purpose (which I doubt anyone was
thinking about much).

But if we assume that "automated use" really means "default use by UAs"
(which is a bit of a stretch, but is at least reasonable) then the section
you quote is just fine, and is in no way contrary to anything I have suggested.
It doesn't help define Reply-To but it doesn't hurt either.

  | This may all be a red herring.  But possibly the appeal to what RCC822
  | appears to say could prove counter-productive to the case you are trying to
  | make.

I'd have no real objection if we were simply to decide that the 822 text on
Reply-To (syntax excepted: I think everyone can understand that part, and we
don't disagree on it) should simply be given up as totally hopeless.  Then
we could go back and decide from first principles what we ought to define
Reply-To to be.

kre

ps: I believe that the two button UI model is broken, almost beyond repair.
I also don't believe that we should be specifying what the UI is supposed
to be, so it doesn't matter that I don't like this model.  If others do, that's
just fine - let's just all agree on what the headers all mean, so implementors
who want to provide that kind of interface can do so in a way that works
reliably.