Errors-to: owner-drums@CS.UTK.EDU
To: Eric Thomas <ERIC@SEARN.SUNET.SE>
Cc: ietf-drums <drums@CS.UTK.EDU>
Subject: Re: Resent- facility 
In-Reply-To: Your message of "Mon, 18 Sep 1995 23:07:22 +0200."
Date: Tue, 19 Sep 1995 08:14:58 +1000
Message-Id: <18305.811462498@munnari.OZ.AU>
From: Robert Elz <kre@munnari.oz.au>

    Date:        Mon, 18 Sep 1995 23:07:22 +0200
    From:        Eric Thomas <ERIC@SEARN.SUNET.SE>

    My UA does display the Resent headers, and thereby isn't
    ignoring them as proposed.

OK, I probably went a bit far in suggesting that they be ignored
that much (not that it would matter anyway, as UA design isn't
a part of 822, or of drums - UA's can show or hide any headers
they deem appropriate).

On the rest of your message, I suspect we are not in such
disagreement as you believe.

For practical purposes, if I want to send (forward, resend,
reroute, ...) a message to someone, and intend them to process
the mail as if it came from the original sender, then I use
Resent-* headers, as you say, that allows various processes to
do the right thing (they look at the From: line, etc).

On the other hand, if I want the mesage dealt with as if I
sent it, and the text I'm sending just happens to look like
another message, then I will use some form of encapsulation
instead - that way the recipient gets to see my From: header.
(Personally I prefer rfc934 encapsulation over MIME, but
never mind).

I believe this is pretty much what you're saying that you need
to be able to do, this is consistent with the use of Resent
that I suggested and Marc agreed with.

Note: if you adopt the "reply to resent-from" rather than "reply
to from" (in the absense of any reply-to stuff), then you have
effectively just made (yet another) structured encapsulation
format.  I'm not sure there is any practical benefit in that.

Finally, once more on fixing ambiguities ... if we were to
decide to simply pack up and run away, we shoudl at least change
the definition of Reply-To, Resent-*, or whatever is at issue
at the time to something like...

	There is a header with the label Reply-To, its meaning
	is undefined.

as that's all we will be ending up with (it is all we have now).
Personally I can't support that, I'd prefer to give it a
concrete meaning - any meaning - rather than simply (effectively)
delete the ambiguous headers, but leaving in a meaningless
definition helps no-one.

Note - these aren't situations where we would be suggesting
changing a clear meaning that exists, just because we think
we could better have a different one, that we can't do.  This
is for cases where there currently is no clear meaning, in
those cases, retaining a half meaning is worse than none at all.

kre