To: drums@cs.utk.edu
Subject: Re: Reply-To (was Re: Issues from the past few weeks) 
In-Reply-To: Your message of "Mon, 22 Sep 1997 17:15:07 MST."
             <34270A0B.BA327658@netscape.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 23 Sep 1997 14:07:00 +1000
Message-Id: <28332.874987620@munnari.OZ.AU>
From: Robert Elz <kre@munnari.OZ.AU>

I started composing this message  when the one from Jamie I'm replying to
arrived, then I got distracted (its the middle of the working day here, and
occasionally work intervenes...) and while I was distracted, a whole bunch
more messages arrived, some of which make some of what I had already said
partly irrelevant, but I'll leave all this here anyway.

    Date:        Mon, 22 Sep 1997 17:15:07 -0700
    From:        Jamie Zawinski <jwz@netscape.com>
    Message-ID:  <34270A0B.BA327658@netscape.com>

First ...

  | But what I am sure of, is that by reading RFC822, it's not obvious to me
  | which of those two implementations of the reply-to-author and
  | reply-to-all commands is closest to the intent of the Reply-To header.

Absolutely.   822 is hopeless (I was going to use an expletive, but
decided it wouldn't help).   We absolutely must fix that, so it is
clear what is meant.

Then...

  | Let's suppose I'm writing an MUA.  Let's suppose I have decided that 
  | in my program, I would like to have two commands, "Reply to Author" 
  | and "Reply to All".

Personally, I wouldn't, I don't think that's really the right model,
I'd have "reply" and a "specialised reply" or something, where the
former does the most common reply, and the latter is a menu with several
options as to where to send the message (most common would be Reply-To
where it exists, otherwise user config either your reply to author or
reply to all).   The menu would let you select from a bunch of possibilities,
including Sender, From, Reply-To To and cc.

But if you have to have reply to author, and reply to all, I'd ignore
Reply-To completely (in all cases), and in the former reply to From
(I guess Sender if there is no From, but that's pretty weird), and
From+To+cc for Reply-All (maybe even +reply-To).   In both of those cases
your user is telling you who he wants to send to (the Author, ie From, or
everyone, is all the reasonable addresses you can find), and clearly doesn't
care where the author would have preferred the replies to go.

  | The sender will reasonably have two expectations of where replies would
  | be sent, depending on the nature of those replies.

I don't agree, the sender either expects a certain kind of reply, in which
case he can suggest where it should be sent, or doesn't know what kind of
reply will be sent, in which case he should say nothing about that.

  | What's important is that Reply-To be defined concretely enough that when
  | I put something in Reply-To, I have some reasonable expectation that I
  | am saying what the recipient *thinks* I'm saying.

Yes, agree totally.

  | This will probably result in the header meaning exactly one thing when
  | (some?) people want to be able to express two different things.

Maybe, and perhaps others want to say 3 differernt things, and others 4 
different things, etc...

  | This probably means that some other header needs to be defined at some
  | point.

Maybe - that's a discussion for some other place at some other time.

  | But, that at least would be progress, because we will know
  | *which* header needs to be added, because we will know *which* header
  | already exists

Actually, I'm not sure, since the way I interpret how Reply-To should be
used it isn't either personal replies, or group replies, but just where I
think replies to this message should go, and sometimes I think the reply
should be a group reply, and sometimes I think the reply should be a
personal reply...   If you like, it is suggesting to the recipient which
of the Reply-To-Author and Reply-To-All buttons he should push (with the
possibility of suggesting other different possibilities).

  | As to your comments about what is and is not a reply: I see your point,
  | but there really do exist two kinds of replies, in addition to the
  | non-replies you talk about.  You say you "almost always" have a kind of
  | reply in mind, but "almost always" is not "always".

No, and when you don't you clearly can't put in a Reply-To header, as you
don't know where the reply should be sent.   This isn't a mandatory header.

  | For example, I might send you (and you only) a reply to this message,
  | which is in fact a reply to your words, and a discussion of the same
  | topic.  The fact that I choose to send my message to you and not to the
  | public doesn't necessarily make it less of a reply.

No, of course not, that would be a reply.   What it wouldn't be would be
a reply to the place I suggested that the reply should go.   That's fine,
I'm not a dictator (as much as I might want to be), you won't be executed
for not caving in to my whims .. you can choose to ignore my request and
simply send your reply to me if you want to.

But that affects nothing, my Reply-To still told you where I think the
reply should have gone (and it is where, in fact, you chose to send the
reply), whether you accede to my request or not is your choice.

  | Maybe you never find yourself in this situation, but I sure do.

Sure, so do I, I often choose to ignore a Reply-To request (most often when
I know it is bogus nonsense, set by someone who is using it because they
can't set From the way they want, or set by a mailing list that insists on
imposing its view onto every message), that's normal.

  | Given that every MUA I've ever used has had two different reply
  | commands,

Actually mine does too - or two different primary reply commands, and about
a dozen more harder to get at - but the distinction between my two major
reply commands is whether or not the text of the message I'm replying to is
included in the reply template or not (with that "  | " marker, etc you see
here), not what address gets used...

(The other reply commands mostly differ as to what From address I use for
the reply, since I have a whole bunch of role type addresses I need to use
at various times).

But I know what you're saying - many UAs have that reply to author/reply to
everyone distinction, and often no way to do anything different (or no way
rational to use).   Whether this was due to user demand, or just someone's
idea what might be nice in the early days I don't know - I do know that
people come to like whatever they first learn though (which applies to
almost everything in life).  That means that many users, used to the two
command paradigm will come to expect that in every UA they use, and will
dislike anything different.

On the other hand, all those people who aren't current users don't have
a mindset already established, and can be trained into almost anything.
Allow them to see a "reply-where-suggested" or "reply-where-I-pick" model
(with those being the two buttons) and I suspect that many will choose
that model over the reply-author or reply-all model.

  | I think I'm probably not the only one.  There are a whole lot
  | of implementors out there who think that these two commands are useful
  | idioms to use.  Authors of specs ignore this kind of real-world
  | feedback at their peril.

If we were writing a spec for UAs that would be relevant, but we're not,
and if UAs want to keep providing those buttons, that's fine.   What we're
doing is writing the spec defining the headers, sent by the author to the
recipients, and containing what the author wants them to contain, and hopefully
doing so in a way that everyone agrees what the headers mean.


Then, in the interim, Paul Fox replied...

pgf@foxharp.boston.ma.us said:
| i think mr. elz would say (and i hope he corrects me if i'm wrong)
| that there is no way for a UA to make that mapping correctly, since it
| cannot know what the _sender_ wanted,

Well, not quite - if Reply-To is defined precisely, then the recipient's
UA should know exactly what the sender wanted, that's the idea.   What it
doesn't know (without considerable smarts anyway) is whether the sender
as intending a group reply or an individual reply - but I see no need for
it to know that.

pgf@foxharp.boston.ma.us said:
| that in fact the if the Reply-to field is used as a destination by the
| recipient's UA then the button should be labelled "Reply to Where the
| Sender Suggested". 

As it happens, that is pretty much what it should do, and pretty much what
I suggested above - and if one is being polite when replying, one will normally
respect that request, so this should be the simple default "reply" button.

pgf@foxharp.boston.ma.us said:
| the unfortunate fact is that this would correctly represent current
| Reply-to practice. 

I'm not sure exactly what is unfortunate, or what is current practice
there - I'm not sure there really is a current practice with Reply-To,
which isn't surprising considering how imprecisely it is specified.

Then Jamie Zawinski responded to this ...

jwz@netscape.com said:
| Well, if that opinion is codified in the successor to RFC 822, I  will
| be sorely tempted to have both my "Reply to Author" and "Reply to All"
| commands just ignore the Reply-To header altogether,

which happens to be just what I had suggested before these other messages
started flying about, and which I think is exactly the right thing to do.
If the user tells you where he wants to send the reply, which both of those
commands are doing, you should respect his wishes, not the original senders.

I think you should add a "reply" command as well though, and make that the
easiest one to select, which does honour Reply-To - that is, the polite
reply to where the recipientw as asked to send it, rather than the damn you,
I'll send the reply where I want to send it options.

jwz@netscape.com said:
| If that's the decision, DRUMS might as well just deprecate Reply-To
| and be done with it.

No, not at all - even if you choose not to use it at all, and never give your
users an easy way to be polite, others won't follow that route, and will allow
an easy way for people to reply to the original author's preferred location(s).

jwz@netscape.com said:
| I think that most of the world currently treats Reply-To as an
| override of From -- a third element on the Sender/From continuum --
| and not an override of To and CC as well.  

I think you may be right, that is slightly more common than any other use,
but its almost totally useless to treat Reply-To that narrowly - it means
the sender has no way to say "please don't include any of the To or Cc
addresses in your reply".   The other definition allows all possibilities, as
the sender can add as many addresses to the Reply-To as he wants.

jwz@netscape.com said:
| If the goal is to document current practice, then there ought to be
| surveys of existing software,

I don't think that's a goal at all, and certainly don't believe it ought to
be.   The aim is to clarify 822, fix the ambiguities, throw out the dead
wood, and make the basic mail standard (not dealing with MIME, encryption
or any of that here) be precise, well defined, and as useful as we can make
it.

I'm entirely willing, should circumstances turn out that way, to have that
cause the standard be written in a way that absolutely no current mailers
implement.   I doubt that will happen, because I doubt we'd have anyone
successfully arguing for a position that no-one has implemented, but should
we convince ourselves that such a thing would be best for mail, then I see
no problem with requiring that (whatever it might be).

And then replying to a message from Perry Metzger...

jwz@netscape.com said:
| I've found that the end result of that kind of approach is that people
| just take the defaults; if it defaults to "all selected", they'll tend
| to use that, and if it defaults to "just one selected", they'll tend
| to use that.

I think Perry's suggestion was that "none selected" would be the default,
(which I see he has now confirmed in yet another message) which would mean
that the users wouldn't be able to just take the defaults they'd have to
select some addresses, and once they start, then they may as well select
sensible addresses.

I know that I wouldn't make such an option the only way to reply, certainly
having a few of the most common cases easier to access would be a design I
think most users would prefer, but I would certainly like to see such an
interface, so on the (comparatively rare) occasions when one of the standard
commands doesn't work the way I want, there is a rational way (which doesn't
involve cutting and pasting addreses) to build the address list that I do
want - that is most frequently when there's been a discussion amongst a group
of people, and I want to send a reply to just a small subset of them - there's
no way you can ever automate that, as no UA will ever be able to tell which
subset I happen to want, but cut & paste (or retype the addresses) isn't a
great interface to use when needed (I know I keep forgetting to stick in the
commas between the addresses when I'm pasting the things...).

But as you say...

  | But now we're talking about UI design, not the semantics of a
  | header field.

which is getting us way off track - except to the extent that you UA authors
need to be convinced that Reply-To, as we want to define it, isn't useless.

It may seem that way if you're stuck with the mentality that "reply to author"
and "reply to everyone" are the two, and only two, reply commands you're
going to provide, ever - and if you believe that no-one else would ever want
to do something different, but that is quite an assumption.   I know that
isn't what I want, my UA really does act the way I describe it above, I have
no "reply to author" or "reply to everyone" commands, just "reply to reply-to"
which defaults to "reply to everyone" when there is no reply-to (and I delete
addresses when that isn't what I want - deleting them is pretty easy, and
turns out better for me that adding a new command I'd probably forget how to
use, and for which there's no space for a gui button in my interface).

kre