Re: [apps-discuss] Trace headers, was Adoption of draft-kucherawy-received-state?

SM <sm@resistor.net> Sun, 15 January 2012 08:59 UTC

Return-Path: <sm@resistor.net>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CB6221F84A0 for <apps-discuss@ietfa.amsl.com>; Sun, 15 Jan 2012 00:59:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.636
X-Spam-Level:
X-Spam-Status: No, score=-102.636 tagged_above=-999 required=5 tests=[AWL=-0.037, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uczoU09G1Mqt for <apps-discuss@ietfa.amsl.com>; Sun, 15 Jan 2012 00:59:41 -0800 (PST)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id D8EB521F849C for <apps-discuss@ietf.org>; Sun, 15 Jan 2012 00:59:41 -0800 (PST)
Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q0F8xLfh017418; Sun, 15 Jan 2012 00:59:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1326617969; i=@resistor.net; bh=it41xNceEZPLkcdgr+Z8vs2A1UStKCInJEbrhwOmDdA=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=BBAUyIcx4RR2Kq6i0CuoVU+XruQS/RrNKl4MIvUeP8CjBXgXdgjWp4soRhJknkt+d uZTw8sBZf1QTNVnltn0QDFTgPMJR62vUqC4/wse2+uWoFL8KmPk5eLfWWmPJvTB7Z+ UPmXbUiNNYd820NIOttD67FvgDQaF+xxwIGExFqE=
Message-Id: <6.2.5.6.2.20120114233239.0ac5fd88@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Sun, 15 Jan 2012 00:54:07 -0800
To: "John R. Levine" <johnl@iecc.com>
From: SM <sm@resistor.net>
In-Reply-To: <alpine.BSF.2.00.1201142235000.1943@joyce.lan>
References: <20120114235207.20340.qmail@joyce.lan> <61D306C70A44794D8930CCB6@PST.JCK.COM> <alpine.BSF.2.00.1201142235000.1943@joyce.lan>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Trace headers, was Adoption of draft-kucherawy-received-state?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 15 Jan 2012 08:59:44 -0000

Hi John,
At 19:55 14-01-2012, John R. Levine wrote:
>If you believe what the RFCs say, there are many more trace headers 
>than those two.  RFC
>  5322 makes a special case of Resent-foo: fields, but they act an 
> awful lot like trace headers.  RFC 5451 says that 
> Authentication-Results "should be treated as a Trace Field."  RFC 
> 5436 says "The 'Auto-Submitted' header field is considered a 'trace 
> field'". RFC 4408 says that "The Received-SPF header field is a 
> trace field."  RFC 5518 says "VBR-Info is a 'trace header field'". 
> That horse left the barn a long time ago. RFC 5537 also lists a 
> bunch of trace fields for usenet, which isn't mail, but it might be 
> a good idea to reserve them to avoid collisions.

The Auto-Submitted header field is defined in RFC 3834.  It 
references RFC 2822 normatively.  RFC 5451 defines 
Authentications-Results and references RFC 5322 normatively.  RFC 
5518 (VBR-Info) references RFC 5322 normatively.  RFC 4408 references 
RFC 2822 normatively.  RFC 5518 likely used the same path as RFC 
5451.  RFC 3834 does not mention Trace Field but RFC 5436 does.

I would say that some of the header fields were defined as "trace 
fields" to restrict the ordering of existing "trace fields header 
lines".  RFC 5322 contains a requirement not to reorder "trace header 
fields".  Most of the header fields can be traced backed to RFC 5322 
as that document defines a syntax for text messages.  Beliefs in RFCs 
could be traced back to the feature sought.

Regards,
-sm