Errors-to: owner-drums@CS.UTK.EDU
Message-Id: <199508170151.VAA25632@wilma.cs.utk.edu>
From: Keith Moore <moore@CS.UTK.EDU>
To: Eric Thomas <ERIC@SEARN.SUNET.SE>
cc: Keith Moore <moore@CS.UTK.EDU>, Chris Newman <chrisn+@cmu.edu>,
        drums@CS.UTK.EDU
Subject: Re: "Reply-To" 
In-reply-to: Your message of "Thu, 17 Aug 1995 00:56:03 +0200."
             <199508162323.TAA18546@CS.UTK.EDU> 
Date: Wed, 16 Aug 1995 21:51:20 -0400
Sender: moore@CS.UTK.EDU

> >I don't see what problem this causes. If the *sender* overrides the From
> >header when  sending a request to  a program, the program  will send the
> >message to where the sender specified.
> 
> Yes, and it  will use the "From:" address as  the executing address. This
> may  not be  the  address that  is  authorized to  issue  the command  in
> question.  This may  not  be the  address  the user  wants  added to  the
> database. Our  premise is that this  is the address where  the user wants
> the replies to this particular message to go.

I suspect we could find a set of rules that lets this work also.

But we're really talking about marginal cases here.  How often does the
person who issues a command to a mail server really need to specify
a different place for replies to go, than the address on whose behalf
the request is actually made?  How many of your users (that hypothetical
5% again) even know how to do this without looking it up in the manual?
How many people's lives are really negatively affected by this, in 
comparison to the number of people who will benefit from more uniform 
reply handling?

When contemplating this kind of change, we certainly need to look 
at those cases, to make sure that we're not adversely affecting a 
huge segment of the user population.  But there are going to be 
some cases were we do make changes that are uncomfortable for some
people.

> >I'm looking for  a set of uniform behavior that  is maximally functional
> >without being too incompatible with the installed base.
> 
> The problem is that the suggestions I've  read so far had the drawback of
> creating  non-negligible compatibility  problems in  a limited  number of
> cases, which  you used  the (guesswork)  "5%" figure  for. Unfortunately,
> this  is  not a  random  5%  distribution over  all  the  user base  (and
> personally I  think it is  much, much more than  5% of all  Internet SMTP
> messages, but  that's besides  the point).  It is  xx% concentrated  in a
> particular  area. The  people  who work  in  this area  are  going to  be
> affected at 95%.  The software products in this area  will be impacted at
> 95%. Since developers do like to get  a paycheck at the end of the month,
> and  since there  is  no  elegant solution  to  the  breakage, they  will
> completely  ignore  your request.  

First of all, I've already stated that I'm looking for ways to "break"
things in such a way that it's quite obvious to implementors as to 
what the "solution" is, even given a mixture of pre-DRUMS and post-DRUMS
clients.  If my current suggestion doesn't meet that criterion, it's
obviously less attractive than it would otherwise be.

> And  since  these "5%"  of  businesses
> generate  95%  of the  usage  you  object to,  the  bottom  line is  that
> absolutely nothing will change and you  will just cause a large number of
> people and  organizations to  waste time pointing  fingers at  each other
> instead  of getting  real work  done. I  don't see  how anyone  benefits.

I don't think things are quite this bad, especially not for this particular
example.  We can state things in terms of "to encourage greater uniformity, 
we recommend that user agents treat from/reply-to as follows:..."  At least
for the case of generating replies, I don't see us outlawing any present
day behavior.  Even if your software doesn't change it's behavior, it's
not a big problem, because the people who send messages to your software
are already having to deal with your software's particular command-set,
error messages, etc.  It's no big deal if they have to deal with your 
software's way of handling From or Reply-to, even if that way seems somewhat
unusual a few years from now.

> Generally  speaking, once  you've released  something you  can only  make
> compatible changes, unless perhaps you act  very quickly. At any rate, it
> is a well accepted  principle that the longer you wait,  the less you can
> make incompatible  changes. And  RFC822 has been  around since  1982. The
> only reason I can think of to  make an incompatible change today would be
> a threat  to the continued  existence of  the Internet. That's  why we're
> here to add things and clarify  language which was obscure, fill in holes
> that  had been  overlooked,  and  not to  change  the  meaning of  things
> millions of  users have  been using  to their satisfaction  for up  to 13
> years.

The reason we're considering such changes is that the millions of users
aren't using Internet mail to their satisfaction.  They're generally
satisfied with how things work in their own environment, the pieces
of software that they adapted to first.  Everything else is "wrong"
or "broken" to anyone who doesn't have the sophistication to read the
RFCs...and even to some of those people.  But there are at least a
half-dozen different ways of interpreting from/reply-to/to/cc when
generating replies, there are problems with mail/news interoperability,
there's lots of places where the expectations of one group clash with
those of another group.

We can't stop people from believing that their way is right.
But we can publish a set of guidelines that generally allows 
things to work well.  Then when people disagree, there will
be an Authority to resolve differences.  It won't change
everybody's minds -- heck, it might change only a few people's
minds -- but over time, it really will result in more uniform
behavior.

Also, we have a counterexample to the idea that you can't make
incompatible changes: MIME.  MIME definitely made life less
comfortable for a significant group of people, but it's being 
adopted anyway, because the benefits from adopting MIME are
perceived to be worth the pain.

> >> Generally speaking, you can't make  a change that significantly alters
> >> the current meaning  without a Darn Good Reason -  a reason that sales
> >> people can  explain to their customers  in a few minutes,  and without
> >> losing the sale.
> >
> >How about "it conforms to RFC XXXX"?
> 
> I'm sorry Keith, but the vast majority of Internet users nowadays have no
> idea how a computer works, how the Internet works, what an RFC is, and if
> you explained it  all to them they  would quickly tell you  that the only
> thing they are interested  in is how come they can no  longer do XYZ with
> the new version of your product when  they've been doing it for years and
> it's saving them hours of work every  month, and how come you expect them
> to actually pay to have that  functionality removed from them. 

In this case, there's no need to make that argument.  You simply add
a switch to your product that causes it to conform to the old behavior.
Or let the old behavior be the default, and add a switch that causes
it to conform to the new behavior.  Or don't change your product at
all, if your customers don't demand it.  

We're not talking about complete failure of your product to interoperate 
with internet mail.  We're talking about the difference in how it behaves 
when the sender resets his From header and doesn't include a Reply-To.  
I have a hard time believing that this is a show stopper.

Keith