Received: from localhost by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id WAA24370; Thu, 14 Sep 1995 22:42:51 -0400 X-Resent-To: drums@CS.UTK.EDU ; Thu, 14 Sep 1995 22:42:49 EDT Errors-to: owner-drums@CS.UTK.EDU Received: from Tomobiki-Cho.CAC.Washington.EDU by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id WAA24356; Thu, 14 Sep 1995 22:42:45 -0400 Received: from localhost by Tomobiki-Cho.CAC.Washington.EDU (5.65+UW95.02/UW-NDC Revision: 2.27.MRC ) id AA05298; Thu, 14 Sep 95 19:42:38 -0700 Date: Thu, 14 Sep 1995 19:38:58 -0700 (PDT) From: Mark Crispin Sender: Mark Crispin Subject: Re: summing up: the meaning of the reply-to header To: "Brent B. Welch" Cc: Keith Moore , drums@CS.UTK.EDU In-Reply-To: <9509150103.AA20216@sage.Eng.Sun.COM> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII On Thu, 14 Sep 1995 18:03:44 -0700, Brent B. Welch wrote: > > 2) forbidden to relocate or reorder ReSent headers > Point 2) is not enforceable, nor should it be. > Many User Agents let users specify what headers they want to see. > The others are scrolled off the top of the display, or eliminated > entirely. Just because it is mandatory for RFC822 doesn't mean > a user wants to see it. You are confusing presentation issues with what is being discussed. Nothing in RFC-822 or the work of the drums mailing list has anything to do with what is presented to users on the screen. It is a reasonable proposal to forbid reordering of ReSent header lines in the header as it exists in bits on the disk. Some MTAs reorder headers. This plus the facts that ReSent isn't specified as a block, nor are they ordered, creates an ambiguity in the chain of resending.