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

Ned Freed <ned.freed@mrochek.com> Sun, 15 January 2012 19:58 UTC

Return-Path: <ned.freed@mrochek.com>
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 E1B4E21F847A for <apps-discuss@ietfa.amsl.com>; Sun, 15 Jan 2012 11:58:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 C+TbtqXRk+CX for <apps-discuss@ietfa.amsl.com>; Sun, 15 Jan 2012 11:58:47 -0800 (PST)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 2D32421F8476 for <apps-discuss@ietf.org>; Sun, 15 Jan 2012 11:58:47 -0800 (PST)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OATDCQE6Z4004MDT@mauve.mrochek.com> for apps-discuss@ietf.org; Sun, 15 Jan 2012 11:58:42 -0800 (PST)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OARPS2OYZK000HW1@mauve.mrochek.com>; Sun, 15 Jan 2012 11:58:38 -0800 (PST)
Message-id: <01OATDCNTH0M000HW1@mauve.mrochek.com>
Date: Sun, 15 Jan 2012 11:51:09 -0800 (PST)
From: Ned Freed <ned.freed@mrochek.com>
In-reply-to: "Your message dated Sun, 15 Jan 2012 19:58:13 +0100" <4F1321C5.7000807@tana.it>
MIME-version: 1.0
Content-type: TEXT/PLAIN
References: <F5833273385BB34F99288B3648C4F06F19C6C15818@EXCH-C2.corp.cloudmark.com> <F5833273385BB34F99288B3648C4F06F19C6C15859@EXCH-C2.corp.cloudmar> <k.com@missing-host.mrochek.com> <AD693E95D4252DC3E8F3832F@PST.JCK.COM> <4F122257.10301@dcrocker.net> <01OAT5KFXSHA000HW1@mauve.mrochek.com> <4F1321C5.7000807@tana.it>
To: Alessandro Vesely <vesely@tana.it>
Cc: apps-discuss@ietf.org
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: Sun, 15 Jan 2012 19:58:48 -0000

> On 15/Jan/12 16:53, Ned Freed wrote:
> >
> > We have a problem to solve here, and unfortunately all of the
> > possible solutions have issues. In my judgement out of all the
> > available options the best is to extend Received:, messy syntax and
> > all. All of the other options, including but not limited to
> > additional trace fields, replacing Received: with something else,
> > replacing Received; while retaining generation of Received; for
> > backwards compatibility, are even worse.

> This judgment is difficult to understand, for me at least, without
> considering an actual alternative.  For an example trace field to be
> paired with "Received:", I'd pick "Sent:".  Consider:

>   Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40])
>     by ietfa.amsl.com (Postfix) with ESMTP id 489FA21F845E;
>     Sun, 15 Jan 2012 08:15:57 -0800 (PST)
>   Sent: to ietfa.amsl.com to-addr 12.22.58.30 to-port 25
>     by mauve.mrochek.com by-addr 66.59.230.40 by-port 1438
>     date "Sun, 15 Jan 2012 08:15:57 -0800 (PST)"
>   Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com
>     (PMDF V6.1-1 #35243) id <01OAT5KHWWNK000FER@mauve.mrochek.com> for
>     apps-discuss@ietf.org; Sun, 15 Jan 2012 08:15:54 -0800 (PST)
>   ...

> That "Sent:" field is to be written on the fly, and if the message is
> rejected (5xx) or delayed (4xx), then the field gets discarded.

> There is a lot of redundant data.  It wastes bandwidth, but can be
> used to check proper ordering, synchronization, and consistency.  The
> format can be similar and new at the same time.  Both fields can be
> extended, but no coordination between their formats is to be mandated.

We went over all of these tradeoffs in tedious detail back in the MIME work.
The original proposal for MIME headers (written by Bob Smart and myself) was 
to add additional paired fields as you are doing here. Once you work through
all the details, all sorts of problems emerge - it's just not possible to keep
the fields ordered due to vagarities of agent processing. This then led to
proposals for linkage ids, but the complexity is such that implementations are
pretty much guaranteed to botch it. (And now you're back to either extending
Received: or abusing the semantics of some existing clause - exactly what the
new field is trying to avoid.)

Encoded words were then proposed by Keith Moore, and rather obviously had
better operational characteristics. Sure, there were bobbles with
implementations that didn't really support proper syntax processing, but in
hindsight it was clearly the right choice.

				Ned