Re: [apps-discuss] Moving ahead with draft-ietf-appsawg-mdn-3798bis

Arnt Gulbrandsen <arnt@gulbrandsen.priv.no> Fri, 05 August 2016 14:29 UTC

Return-Path: <arnt@gulbrandsen.priv.no>
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 465F212D1BE for <apps-discuss@ietfa.amsl.com>; Fri, 5 Aug 2016 07:29:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gulbrandsen.priv.no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Td6sJ95SvPAU for <apps-discuss@ietfa.amsl.com>; Fri, 5 Aug 2016 07:29:54 -0700 (PDT)
Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C14512B037 for <apps-discuss@ietf.org>; Fri, 5 Aug 2016 07:29:54 -0700 (PDT)
Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 39CD3FA00F9; Fri, 5 Aug 2016 14:29:51 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1470407391; bh=9pAEWOixDqg7efsojFHuFLfGe8KVv6mefAKBfbDHH5c=; h=From:To:Subject:Date:In-Reply-To:References:From; b=iBmsHLoUjNnR4wyZE439KG4v1PV2pC24+4SgxKGSDEEiOLPH/CHkuCIS4zI8PzD+5 6DEAHqnuyqqQUeB1GpeovBL2jLYebbDJpS3iqpzpv1wxEg+mBvRhZn/MZxanS2x3ZR 0msPaD9sCEqWpxZElKEtDS0wJPhZ6kdl0xXq2KCI=
Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1470407390-8864-25249/12/232; Fri, 5 Aug 2016 14:29:50 +0000
From: Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>
To: IETF Apps Discuss <apps-discuss@ietf.org>
Date: Fri, 05 Aug 2016 15:29:46 +0100
User-Agent: Trojita/v0.5-9-g8961725; Qt/4.8.6; X11; Linux; Debian GNU/Linux 8.5 (jessie)
Mime-Version: 1.0
Message-Id: <459e7377-b699-4f48-95f0-627a0501e916@gulbrandsen.priv.no>
In-Reply-To: <E3D7A2D2FA915AAA09DDE1EE@JcK-HP8200>
References: <CAL0qLwaPNr5ptb0UGD0_TorqYRuH_6PSSwtNuQ0wGCKbDuxKgw@mail.gmail.com> <E4AA7EB24E12F5FAE7D4C50B@JcK-HP8200> <bfc181aa-0086-582c-c54f-ad5820366a9e@isode.com> <47872C0B5B5198E8126F5469@JcK-HP8200> <cf8b8297-bb2f-ad0c-710c-5ee36b859885@isode.com> <E3D7A2D2FA915AAA09DDE1EE@JcK-HP8200>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/apps-discuss/KqZLCsY0CCC-88b6ThhtRIyPP7w>
Subject: Re: [apps-discuss] Moving ahead with draft-ietf-appsawg-mdn-3798bis
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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: Fri, 05 Aug 2016 14:29:56 -0000

John C Klensin writes:
> (again, see Arnt's notes, most of which have not been
> posted to this list).

I can sum up on the list, or perhaps restate.

RFC 6533 is not a very long RFC, but it is bothersomely complicated, most 
of the complexity is not central to its purpose, and it's not being 
implemented as much as the neighbouring RFCs. The parts of that sentence 
are causally related, I think.

I am proposing to replate 6533 with a simpler version. I want to simplify 
section 3 (about ORCPT) so that only the first two productions in the 
formal syntax are needed. (This affects what happens when the message path 
includes a standards violation. There is no change as long as the MTAs 
follows the RFCs.) I also want to simplify section 4.5 (DSN generation) so 
that it's possible to generate a DSN without reference to the DSN's 
recipient's SMTP server's SMTP extensions. If possible perhaps simplify a 
few other bits of section 4.

I have volunteered to do the editing. I probably add an example or two 
while editing.

IMO, 3798bis should incorporate what it needs from 6533(bis). Reading and 
implementing partly related documents is harder than it needs to. Separate 
documents is convenient for us, that's IMO less important than having 
implementers be able to read and understand.

Arnt