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
- Re: [apps-discuss] Moving ahead with draft-ietf-a… Arnt Gulbrandsen
- Re: [apps-discuss] Moving ahead with draft-ietf-a… John C Klensin
- Re: [apps-discuss] Moving ahead with draft-ietf-a… Alexey Melnikov
- Re: [apps-discuss] Moving ahead with draft-ietf-a… Alexey Melnikov
- Re: [apps-discuss] Moving ahead with draft-ietf-a… John C Klensin
- Re: [apps-discuss] Moving ahead with draft-ietf-a… John C Klensin
- [apps-discuss] Moving ahead with draft-ietf-appsa… Murray S. Kucherawy