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 15:10:18 +0200."
             <199509181317.JAA01401@CS.UTK.EDU> 
Date: Tue, 19 Sep 1995 05:38:35 +1000
Message-Id: <18165.811453115@munnari.OZ.AU>
From: Robert Elz <kre@munnari.oz.au>

    Date:        Mon, 18 Sep 1995 15:10:18 +0200
    From:        Eric Thomas <ERIC@SEARN.SUNET.SE>
    Message-ID:  <199509181317.JAA01401@CS.UTK.EDU>

    The  only reason  it works  in your  case is  that the
    autoresponder software  you use ignores the  "Resent-" fields completely,
    which  is certainly  not  commendable behaviour  (what's  the purpose  of
    having them in the first place if you're going to say that they should be
    ignored???)

I'm not sure about that.   I am coming to the opinion that Resent
headers should be treated in much the same way as Received,
that is, they provide a log of message relaying, that can be
examined, but apart from that, should basically be ignored.

Obviously they differ from Received, in that the message relaying
function being indicated is rather different, being done
deliberately by a human (or an automaton acting for a human)
rather than simply by an MTA passing the message through, but
message relaying is basically what is being indicated there.

That would imply that UA's should generally take no specific
notice of Resent headers when displaying, replying, etc, to
a message that contains them, instead using purely the original
headers.

I don't think we should deprecate the headers, they do serve a
useful purpose (not that we couldn't achieve much the same by
simple UA functionality, with no specific headers at all, but
with a loss of potential information to the recipient).

What we do need to do is more clearly document them, and in
particular list which headers it makes sense to have a Resent
version of.   I doubt that a Resent-Content-Id: makes any
sense, and even if using Resent-Received might be technically
better than Received once a message has been Resent, I don't
think we're about to make that happen now.

I once (re-)sent a message with a Resent-Subject in it - as a
way to pass comments of mine to the (many) recipients (it was
to a list) which I thought at the time as being rather convenient,
until it was pointed out to me that most UA's probably never made
it easy, if indeed possible, for the recipients to even see the
thing.   I don't think I'd do that again.

Resent-{To,Cc,From,Bcc,Date,Message-Id} all make sense as part
of the function of logging relaying - it even makes sense to
have several sets of those in one message, if it has been
Resent several times.

Others are harder - does Resent-Reply-To make any sense?
My current take is no - partly because I believe we need to
allow several Resent header sets, and several Resent-Reply-To
headers would be a bit tricky to attempt to make good sense of.
Further, as the aim of Resent is (seems to be) to allow messages
to be relayed by humans, I'm not sure it makes sense for the
relaying human to want to be fiddling the reply addresses, etc.

So, I think I'd support language to clarify the Resent headers
as being relaying documentation, and not intended for other
purposes.   In particular "Reply" functions shouldn't be going
near any Resent headers, unless the user deliberately makes that
happens (the user is in ultimate control after all).

kre