Re: [apps-discuss] Adoption of draft-kucherawy-received-state?

SM <sm@resistor.net> Thu, 19 January 2012 00:27 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 7FD7311E80D7 for <apps-discuss@ietfa.amsl.com>; Wed, 18 Jan 2012 16:27:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.632
X-Spam-Level:
X-Spam-Status: No, score=-102.632 tagged_above=-999 required=5 tests=[AWL=-0.033, 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 fkmVfKPHDE-T for <apps-discuss@ietfa.amsl.com>; Wed, 18 Jan 2012 16:27:32 -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 78BAF21F8582 for <apps-discuss@ietf.org>; Wed, 18 Jan 2012 16:27:32 -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 q0J0RNkA021416 for <apps-discuss@ietf.org>; Wed, 18 Jan 2012 16:27:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1326932851; i=@resistor.net; bh=FqeohgF/Cyg5aFNFK16vi1xZKPlGmE4ijiih7X93OQ8=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=sDylpu1GVroIvQWfYKtzrryeL4a/7WJM7tutvxW5A8001Ivrjje0P0kf1/+UeK6lI sGK+gOe5GaBxu8uVUTABiOJRAMxSdCzzie8BWDoHC/tb9bo/Zkf2EUMdygKhAeFu6M V9vqrQx3g6azxooLaN+Buulwq/F69nyhs3IV4T5I=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1326932851; i=@resistor.net; bh=FqeohgF/Cyg5aFNFK16vi1xZKPlGmE4ijiih7X93OQ8=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=wcSgdYZwOhT2Q8wX4oOjNfsHC1Um07Pq+zddlVqLblhbh3HUyn86fn2VjYVp7jXka QYCeybsUTHh9y2WRxToogoCRJJaHSeyUL3qoNCqhbM56VdKlVZYuu4Taf3S0Qf1osE Dd40R0tc9/Vd43JjFkPWYf1KOEuK+e+hXP3QZI5E=
Message-Id: <6.2.5.6.2.20120118155854.0a1c4730@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Wed, 18 Jan 2012 16:19:58 -0800
To: apps-discuss@ietf.org
From: SM <sm@resistor.net>
In-Reply-To: <F5833273385BB34F99288B3648C4F06F19C6C158FD@EXCH-C2.corp.cl oudmark.com>
References: <01OAT5KFXSHA000HW1@mauve.mrochek.com> <20120115200833.33736.qmail@joyce.lan> <01OAUJAX2HRI000HW1@mauve.mrochek.com> <3EBF175E9FCAA85080916A79@[192.168.1.128]> <F5833273385BB34F99288B3648C4F06F19C6C158FD@EXCH-C2.corp.cloudmark.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: Re: [apps-discuss] 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: Thu, 19 Jan 2012 00:27:33 -0000

Hi Murray,
At 15:20 18-01-2012, Murray S. Kucherawy wrote:
>And an interesting observation: When I wrote RFC5451, my goal was to 
>call Authentication-Results a trace field specifically because 
>preserving the order of addition of Received fields with this mixed 
>in is an important hint to figuring out where, and perhaps why, 
>message authentication work ran into problems.  So I only wanted to 
>piggyback on the "don't reorder or change this" rule that had 
>already been laid out rather than re-stating

Several other specifications have followed the piggyback path.  In my 
opinion, the question is worth discussing as it is not clear whether 
it is an acceptable practice.

>  it.  However, it also has an end-user purpose, which you correctly 
> called post-delivery MUA information.  That part isn't exactly 
> trace information per se, or maybe it is but it's actually 
> MUA-actionable.  So that header field is actually a mix of both 
> types of header field, I suppose: Agents should all follow trace 
> header field handling rules, but it actually contains actionable 
> stuff.  I'm hoping it doesn't thus deserve its own hybrid category...

It's easier to pretend not to see this part instead of trying to come 
up with a hybrid category. :-)

>I think perhaps the amalgamated draft we seem to see forming between 
>John's and SM's proposals might do well to talk about situations 
>where each approach (Additional-Registered-Clause vs. new header 
>field) is more appropriate.

I haven't discussed the approach to take with John Levine.  I don't 
have a preference at the moment.

Regards,
-sm