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

On Wed, 16 Aug 1995 18:48:40 -0400 Keith Moore <moore@cs.utk.edu> said:

>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'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.  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.
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.

>> 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. You better
have a good answer that includes both a description of how they can still
do it today,  just in a different  way, and why it was  necessary to make
this change.  And the  new method  had better  work, not  in 5  years but
today, because you've pulled the old method today. Yes, it probably means
the Internet has to live with its  past mistakes. I can think of hundreds
of examples in the industry. It's tough, but that's life.

  Eric