Message-Id: <199710222126.RAA06281@spot.cs.utk.edu>
From: Keith Moore <moore@cs.utk.edu>
To: Graham Klyne <GK@acm.org>
cc: Keith Moore <moore@cs.utk.edu>, drums@cs.utk.edu
Subject: Re: "Reply-to as a replacement for From" considered hopeless 
In-reply-to: Your message of "Wed, 22 Oct 1997 10:15:35 -0000."
             <3.0.32.19971021211044.007a8ed0@pop.dial.pipex.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 22 Oct 1997 17:26:50 -0400
Sender: moore@cs.utk.edu

> >> No proposal seems to make it easy to fix this without some kind of upgrade
> >> to the installed base.
> >
> >I agree.
> 
> I would observe that it is easier to upgrade servers than clients.

I'm not sure what you mean by this, but I'll guess that by "servers"
you mean "list servers" and by clients you mean "MUAs".

Let me therefore state this more clearly:

No proposal will fix the problems with reply without some kind of
upgrade to both MUAs and list servers.  It's not an either-or choice.


> I'm not clear whether that's a "yes" or "no", but I think that, on balance,
> it's a "yes".  Which I think poses a deeper problem.
> 
> Should we, to paraphrase Eric Raymond, make a decision on the grounds of
> process regardless of what we may feel about the technical issues, or draw
> out the discussion of the technical merits even if it would in the
> perception of some be stretching the scope of DRUMS?  Not an easy
> question...

Harald may shoot me for saying this, but...

I don't think DRUMS can make a sane decision on reply behavior without
considering a complete proposal.  

For instance, I think it's generally understood that "Reply-To
replaces only From" is broken without some additional mechanisms.  

But there seems to be a great deal of faith (which I do not share)
that "Reply-To replaces only From" *can* be fixed by adding additional
mechanisms.  Until the DRUMS group has a shared understanding of what
those mechanisms are, it cannot evaluate the quality of the fix.  

> >The question of how to deal with Reply-To is thus a a user interface 
> >problem -- how to alert the recipient to the presense of Reply-To, 
> >and how to make it easy for the recipient to respect the sender's 
> >wishes as expressed through Reply-To, while still allowing the 
> >recipient to reply to other addresses if he or she chooses.
> >
> >Note that this problem is the essentially the same regardless 
> >of how the sender expresses his reply-to preferences.  Adding 
> >new *-Reply-To fields doesn't make it any easier to construct 
> >an effective user interface.  Depending on the specific proposal,
> >it may make it more difficult.
> 
> I think your response here suggests that it would probably be easier to go
> for a "simplistic" interpretation of "reply-to" (per the "reply-personal"
> proposal) and leave it as a UI issue to sort out the different kinds of
> response.  And to discourage the further introduction of new
> headers.

I disagree.  I dislike Reply-personal because it is much less
functional than Reply-all.  I also believe that once you deal with the
extra protocol features that Reply-personal needs to be a *complete*
proposal, the UI for Reply-personal gets more complex than the one for
Reply-all.

In general, I want to discourage introduction of new headers precisely
because they make the UI more complicated.  Unless authors really need
to specify group-reply-to separately from personal-reply-to (and I
haven't seen any evidence to support this this), there's no reason to
have separate header fields for each case.

> I do think there may be a terminology problem, though, in the sense that
> (as I interpret the words) the proposed description of "reply-to" called
> "reply-personal" seems to more closely describe "follow-on" semantics
> rather than "reply" semantics.  But then, people tend to think in terms of
> "reply" even if they are actually doing what might be more precisely
> described as "follow-on"?

I don't know what "follow-on" means.

> Again, this suggests to me that this is fundamentally a UI issue, not a
> protocol issue.

Yes.  But we still have to define what Reply-To means.  Is it:

a) where the author wants replies to be sent, or
b) where the author wants replies to the author to be sent?

I find (a) a very useful and desirable feature.
(b) doesn't add enough value over From/Sender to make Reply-To worth having.

Keith