Errors-to: owner-drums@CS.UTK.EDU
Date: Fri, 15 Sep 1995 04:06:13 +0200 (MET DST)
From: Jacob Palme <jpalme@dsv.su.se>
To: Keith Moore <moore@CS.UTK.EDU>
Cc: ietf-drums <drums@CS.UTK.EDU>
Subject: Re: Another header-munging example 
In-Reply-To: <199509141628.MAA21052@wilma.cs.utk.edu>
Message-Id: <Pine.SUN.3.91.950915034922.24926H-100000@ester.dsv.su.se>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Thu, 14 Sep 1995, Keith Moore wrote:

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

You assume that it is possible to get general acceptance of a hew
definition of "Reply-To". The disagreement within our own discussions
does not seem to indicate that this assumption is true.
> 
> 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.
> 
In the case of a new more precise definition of "Reply-To" you
assume that implementors will eventually conform to the new
definition. In the case of the two new headers to replace
it, you assume that implementors will not eventually conform
and this that the problem will be even worse.

I would assume the opposite. Because a more precise definition
of "Reply-To" will either keep the ambiguity, or cause one
interpretation to lose, there is a large risk that there
will be no eventual conformance to the standard.

With two new headers, in the other case, both groups will
be able to do what they wa,t so the probability of eventual
conformance will be larger, not less.

Also, even if some implementations will not implement the
two new headers, and some will, the confusion will never
be more than today. See the following table:

New standard used by sender	Yes	Yes	No	No
New standard used by recipient	Yes	No	Yes	No
Confusion			None	- Same as before -

All changes and new features in standards always have a risk
for causing confusion if people do not conform to them.

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

It all comes down to how important you feel the change is.
You do not perceive the "Reply-To"-problem as serious, while
I do. This is probably because we have different background
experience. I have probably been working more with development
of advanced group communication systems than you have, and
therefore feel the importance of getting rid of a confusion
for group communication applications of e-mail more strongly
than you do.

I also feel that "Resent-" is less of a problem, because
few use it, while "Reply-To" is more of a problem, because
it is in my experience used more than "Resent-".

------------------------------------------------------------------------
Jacob Palme <jpalme@dsv.su.se> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/~jpalme