Re: [apps-discuss] possibleTrace fields registry

Dave CROCKER <dhc@dcrocker.net> Tue, 17 January 2012 18:06 UTC

Return-Path: <dhc@dcrocker.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 2E6CF21F8475 for <apps-discuss@ietfa.amsl.com>; Tue, 17 Jan 2012 10:06:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.885
X-Spam-Level:
X-Spam-Status: No, score=-6.885 tagged_above=-999 required=5 tests=[AWL=-0.286, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 Y0t6jriHnYX2 for <apps-discuss@ietfa.amsl.com>; Tue, 17 Jan 2012 10:06:39 -0800 (PST)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8767721F8474 for <apps-discuss@ietf.org>; Tue, 17 Jan 2012 10:06:39 -0800 (PST)
Received: from [192.168.1.11] (adsl-67-124-148-117.dsl.pltn13.pacbell.net [67.124.148.117]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q0HI6Xlr024990 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <apps-discuss@ietf.org>; Tue, 17 Jan 2012 10:06:39 -0800
Message-ID: <4F15B8A7.9080907@dcrocker.net>
Date: Tue, 17 Jan 2012 10:06:31 -0800
From: Dave CROCKER <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: apps-discuss@ietf.org
References: <20120115201817.34086.qmail@joyce.lan> <4F15A667.4030708@dcrocker.net> <F5833273385BB34F99288B3648C4F06F19C6C158B7@EXCH-C2.corp.cloudmark.com>
In-Reply-To: <F5833273385BB34F99288B3648C4F06F19C6C158B7@EXCH-C2.corp.cloudmark.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Tue, 17 Jan 2012 10:06:39 -0800 (PST)
Subject: Re: [apps-discuss] possibleTrace fields registry
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: dcrocker@bbiw.net
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: Tue, 17 Jan 2012 18:06:40 -0000

On 1/17/2012 9:33 AM, Murray S. Kucherawy wrote:
>> This has been an interesting exercise. I had not previously noticed
>> that RFC5321 and RFC5322 have conflicting definitions of 'trace'.
>> RFC5321 equates it only to Received.  RFC5322 uses it to describe a
>> class of fields.
>
> I don't see this as being a conflict.  RFC5322 defines a trace field in general terms, and RFC5321 discusses one specific instance of a trace field, namely Received, as being the only one SMTP itself cares about.  It doesn't mean there aren't others, but an MTA doesn't do anything special with them (i.e., doesn't add any new ones).


Except that that's not what RFC5321 says.  Your interpretation actually requires 
some linguistic creativity.  RFC5321 does not note a larger concept, with 
Received being an instance.  It simply uses the one term to refer to the one 
header field.  (IMO, RFCs 821 and 822 created the problem of redundant and 
sometimes divergent definitions, though I hadn't noticed this one before.)

So I think that what you've really done is suggest a simple and reasonable fix, 
requiring only a small amount of wording change to RFC 5321.

When <trace> was a loosely-used term, the disparity didn't matter much.  But 
since there is talk of formalizing the construct further, we should be careful 
about the details and not relay on assumptions about interpretation of 
specification text.  Note, for example, the view that /any/ trace field can be 
repeated...

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net