Errors-to: owner-drums@CS.UTK.EDU
Message-Id: <199509141628.MAA21052@wilma.cs.utk.edu>
From: Keith Moore <moore@CS.UTK.EDU>
To: Jacob Palme <jpalme@dsv.su.se>
cc: ietf-drums <drums@CS.UTK.EDU>, moore@CS.UTK.EDU
Subject: Re: Another header-munging example 
In-reply-to: Your message of "Thu, 14 Sep 1995 17:39:12 +0200."
             <Pine.SUN.3.91.950914173829.23053E-100000@ester.dsv.su.se> 
Date: Thu, 14 Sep 1995 12:28:36 -0400
Sender: moore@CS.UTK.EDU

(from the floor :) )

> If existing 822 headers are interpreted in two different ways
> by much existing software, then there is an obvious risk that
> the outcome of the process you describe will be either:
> 
> (a) An ambiguous compromise to make everyone happy, but keeping
> the two different interpretations and the trouble which is caused
> by them.
> 
> (b) Recommending only one of the two, after which much existing
> software maybe will not follow the new standard because they do
> not like it.

Other outcomes are possible.  In particular, I believe it is possible
to *encourage* (rather than mandate) a narrower set of behaviors
for mailing lists which is more-or-less compatible with the installed 
base of user agents.  Present-day lists might not change their behavior,
but new lists might be more likely to adhere to the recommended behavior.
(some present-day lists might offer the recommended behavior as a 
per-recipient option.) Eventually we would gain uniformity than
we have now -- the rate being governed by how well the recommended
solution meets people's needs.

Of course this requires that we have agreement that more uniform 
behavior is a good idea, and also that we can recommend a behavior
for lists which satisfies most people's needs.

But the danger of defining new headers  to solve an old problem (even 
two new headers to replace an existing one as Jacob suggests) is that 
we *widen* the set of behaviors that lists and user agents have to 
cope with.  For the case of *-reply-to, some user agents will still 
use the old reply-to to form replies (with all of the variants on 
*that* behavior), some use the new reply-to headers, some simply use 
the new ones in preference to the old.  Some lists will add the new 
reply-to headers but continue to mung the old headers, some lists 
will only add the new ones, some lists will only mung the old ones.

...which is not to say that I'm against new headers, but the above
scenario is one I'd like to avoid.  For things like Resent-* which
are arguably broken and useless as-is, I'm all for defining new
field names.  For things like reply-to which are arguably working
to some degree, I'd rather simply try to stop things from deteriorating.

Keith