Errors-to: owner-drums@CS.UTK.EDU
Message-Id: <199509182233.SAA22221@CS.UTK.EDU>
Date:        Mon, 18 Sep 1995 23:07:22 +0200
From: Eric Thomas <ERIC@SEARN.SUNET.SE>
Subject:     Re: Resent- facility
To: Mark Crispin <mrc@Ikkoku-Kan.Panda.COM>, Mark Crispin <MRC@Panda.COM>
cc: Robert Elz <kre@munnari.oz.au>, ietf-drums <drums@CS.UTK.EDU>
In-Reply-To: Message of Mon, 18 Sep 1995 13:43:33 -0700 (PDT) from Mark Crispin
             <mrc@Ikkoku-Kan.Panda.COM>

On Mon,  18 Sep  1995 13:43:33 -0700  (PDT) Mark  Crispin <MRC@Panda.COM>
said:

>That's a mistake. If the message  was intended to be forwarded, it would
>have been forwarded.

What can I say Mark, there's  no real definition of forwarding in RFC822.
The only time  the word appears together with a  technical description is
when it describes  the "Resent-" tags. So maybe, being  one of the people
who took part  in the discussions, *you*  know what was meant.  To Joe Q.
Reader, RFC822 sounds very much like  something that says this is the way
you forward mail. Anyway, I've used, for many years, mail interfaces that
have one forward command, and this command is what you call "resend", and
nobody ever expressed a  need for anything else. And this  was one of the
most popular UAs before Eudora and PINE took over.

>That  is a  deficiency in  your UA.  Your UA  should display  the ReSent
>headers.

My UA does display the Resent headers, and thereby isn't ignoring them as
proposed. Conversely my  UA ignores the Received: headers  by hiding them
unless I explicitly ask to see them.

>Trust me, I  was there. ReSent was intended to  standardize and document
>what MM and Hermes provided with the Remailed and Redistributed headers.
>(...)  Blame  certain   individuals  who  didn't  want   "two  kinds  of
>forwarding".

Lots of good all  of this does me. The fact is that  there is now a large
community of people who've read in  RFC822 what was written in RFC822, as
opposed  to  what  certain  individuals  who didn't  want  two  kinds  of
forwarding meant, but did not end up writing because it was controversial
and controversy  is bad, so  let's be ambiguous instead.  XMAILER (1982?)
used Resent-  fields to  implement mail  forwarding and  RiceMail (1984?)
used  them for  the FORWARD  command. When  showing origins  and deciding
where to reply,  the Resent- fields took precedence.  Same with LISTSERV,
NETSERV, and  a bunch of  other applications, and  a bunch of  MTAs. It's
much too late now to decree that the RFC only ever meant for these fields
to have  an ornamental purpose.  If you  clarify that the  "Resent-" tags
have to be ignored, as far as the software I maintain is concerned I will
just  have to  document that  I disagree  with the  clarification, partly
because there are people who have procedures based on that which would be
broken, and  partly because there is  no real alternative. I'm  sorry but
the  "forward"  method  is  brain damaged  where  automated  servers  are
concerned.  There's  no clear  signal  that  says  "This is  a  forwarded
message, and if you  look inside the body you will  find a second header,
which you  should use in  place of the first  one for information  on the
original  sender".  Oh  yeah,  it  usually  says  "fwd"  in  the  subject
somewhere,  although  sometimes it's  "by  way  of", and  sometimes  they
translate it too.  Highly dependable. Anyway, this isn't a  usable way to
indicate to  a piece of software  that you've forwarded something  to it,
and that the forwarder  is X but the original author is  Y. One may argue
that RFC822  doesn't define  a clear,  generic forwarding  mechanism, and
that it's thus outside the scope of this group, and I'm willing to agree,
at least partly. But RFC822  does define a mechanism called "forwarding",
which I am now told was never  meant to be used to actually forward mail,
but which  many people have  used for that  purpose for lack  of anything
better, and which actually solved their  problem. If you mandate that the
"Resent-" fields be ignored, we're left with nothing.

And we're back  to the philosophical debate about whether  this group has
to fix all ambiguities or run when faced with hard choices. Personally, I
don't think that's  the real issue. It  is a fact of  life that sometimes
people screw  up, and  that happens  even in  standards, and  when you've
screwed up there's a *small* time  window during which you can say "Wait,
wait, I screwed up! Stop everything, I meant something else!" After that,
changes can only be made through  a smooth migration path. And if there's
nothing to migrate  to, you remain where  you are. This goes  for all the
things we discuss  here. The key question is "What  is the alternative if
we remove  X, and  how disruptive  is it going  to be  for the  users and
programmers?", not "How controversial is this issue?"

  Eric