Re: [apps-discuss] Confused about draft-ietf-appsawg-mdn-3798bis-11.txt

Shawn Steele <> Thu, 04 August 2016 21:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 60CD512D81B for <>; Thu, 4 Aug 2016 14:06:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.022
X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zerBKAI2KZgh for <>; Thu, 4 Aug 2016 14:06:02 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4D27812D78E for <>; Thu, 4 Aug 2016 14:06:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=GmG95G7dhU6OWjs4PoRzjVvStpGGEh9LMUXHO2qL9Qs=; b=cLCc30fUP6+Jz/BGNPGyK0sDyOoGysltZWAot4lzPY1RryV8X1s321PTwCf3bw3KQIHynTsbIp+x2B6pXis+QyCXZSVXtLeLBqYpoiinyTFWdQwncrXWvM+AyVHNGSV62W/3b+kx7KUY5yrwIT+6pTIAd+jjFoae2EPz4i57RRg=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.15; Thu, 4 Aug 2016 21:05:59 +0000
Received: from ([]) by ([]) with mapi id 15.01.0549.023; Thu, 4 Aug 2016 21:05:59 +0000
From: Shawn Steele <>
To: John C Klensin <>
Thread-Topic: [apps-discuss] Confused about draft-ietf-appsawg-mdn-3798bis-11.txt
Thread-Index: AdHuiKUhm5GAAtbwSw+fzH9gzCSaBAABgNeAAAE7TwA=
Date: Thu, 04 Aug 2016 21:05:59 +0000
Message-ID: <>
References: <> <65CD4EEE481E0F48F4DD6EE5@JcK-HP8200>
In-Reply-To: <65CD4EEE481E0F48F4DD6EE5@JcK-HP8200>
Accept-Language: en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is );
x-originating-ip: [2001:4898:80e8:9::b2]
x-ms-office365-filtering-correlation-id: 5767bcd4-c35b-4a43-17e0-08d3bcab2295
x-microsoft-exchange-diagnostics: 1; CY4PR03MB2742; 6:a2f5bTnqH7xbLbjvGHFVzD+r0HoUB4f0Ce5Dx/2QxYyKGd0TdYIUxq1Dsx9zbeHl2bFF6scyToTbpHDti/6hag68kVDoDBnxKmhHgWDdCeS+7gGa9HBnM1Iuo7fcDxkZKTCxraoMMPL3JR8+Oxl1EAsNiDO2fHZxOsoWrUU9zxHCvI5YVLt/mYqtrRh25uIc59NwQNL+g91B+G0y82/v2FCNTThL7Hj0iDbt3tV3vYkK5JTltlEXzyo+hnohORh5MMIAwm72ALzGhXgXs8YMxXF39yVyEvYuUoMw5wFUytSKdGSAAEUdFQPdXHFRH3AMHaFYeePksqaqcyPW20Chdw==; 5:MlWl/3PcTyYMeq4Om7yYcdCQfAHcpnHSUrzV5okGi8OQ4FUB4srl41NWkkC8ooaeDhmGW6131OEhI27GlKPPr4fCCASP0W+f/fK+h8Itk+4FlcAktKNWgfGN6IA32pEKwc8dXeIllumgBIG8dOfPuA==; 24:s2EZUrlfUHf5Ez06UeM+vNXlOxOR8r0m31HagjZOrcq5CAIZNX+oA2Ogp24WT9nEhRxCD2pj3lkas8n9KB+w6X2AYCqlZ4uxJsxS81SNcTM=; 7:dZFbshrmcvOdYwEb7q35UtWMPizosYW79zDL43Jc35YCSnZAhY+n7rXNe0N5bHn+MD68acRkM1KNR6fJmIgYfSVjTEOaiHdq8oQ9e5t2h/daj6EBCHrfC5yoJNJsSsTEWv+osvlbuLCxhwBIHjD6pHQW9gB1Rm3hb3meW6eli+DC/YubvRuNoIif++PJ+tkgJZU94OWLARXcp1FGK3aUGcVDPLfqPHinBhyc7LUXiZJZhFkVu9MAj4+3jhKsq8jN
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY4PR03MB2742;
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:CY4PR03MB2742; BCL:0; PCL:0; RULEID:; SRVR:CY4PR03MB2742;
x-forefront-prvs: 00246AB517
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(199003)(24454002)(52314003)(13464003)(189002)(9686002)(97736004)(8676002)(10090500001)(10400500002)(10290500002)(230783001)(5005710100001)(586003)(86612001)(68736007)(101416001)(5002640100001)(76176999)(92566002)(99286002)(3660700001)(8990500004)(81166006)(110136002)(11100500001)(81156014)(189998001)(54356999)(86362001)(105586002)(8936002)(50986999)(7696003)(74316002)(7736002)(102836003)(6116002)(77096005)(305945005)(2906002)(3280700002)(4326007)(2900100001)(2950100001)(7846002)(122556002)(106356001)(33656002)(87936001)(19580405001)(19580395003)(76576001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR03MB2742;; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None ( does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Aug 2016 21:05:59.3186 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR03MB2742
Archived-At: <>
Cc: "" <>
Subject: Re: [apps-discuss] Confused about draft-ietf-appsawg-mdn-3798bis-11.txt
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 04 Aug 2016 21:06:04 -0000

Ok, new probably wasn't a great choice.  Updated anyway, and I'd rather it build off of the other more recent thinking rather than have the potential forked path.  It's way easier to support an A + B + C scenario than an A, maybe-B, sometimes-C, perhaps all three scenario.  

Additionally it would simplify the spec (and thus the implementation) if you can take SMTPUTF8 as a prerequisite, then you can get rid of the 7-bit and other compat stuff.


-----Original Message-----
From: John C Klensin [] 
Sent: Thursday, August 4, 2016 13:28
To: Shawn Steele <>
Subject: Re: [apps-discuss] Confused about draft-ietf-appsawg-mdn-3798bis-11.txt


Thanks for taking a look.  A clarification or two below in the hope of saving time....

--On Thursday, August 04, 2016 19:48 +0000 Shawn Steele <> wrote:

> This draft just came to my attention, so I'm probably missing a ton of 
> interesting context, but I have a couple
> questions/observations:
> ·        This is a new mechanism, so I'd prefer it be
> dependent on other new things.  Such as depending on UTF8SMTP instead 
> of designing other mechanisms for non-ASCII content.
> I'd go so far as to require UTF8SMTP as a prerequisite.

I don't see this as a new mechanism, so much as tuning of the original MDN specifications through RFC 3798.  The SMTPUTF8 (remember we switched the term around to distinguish the standards-track machinery from the earlier experimental specs) MDN machinery, described in RFC 6533, is very much dependent on and, IMO, evolutionary from, 3798.

That said, I'm quite concerned about our going, instead of a path like the one you are suggesting which I see as

   3798 -> 6533 -> maybe 6533bis -> unified MDN spec


   3798 -> 6533 -> eventual 6533bis
         -> 3798bis -> ...

and would see an SMTPUTF8 prerequisite to unified MDNs, or at least a unified MDN model that didn't require handling separate from SMTPUTF8/6533[bis?], as highly desirable in that regard.
See my longer note from earlier today for one view of the details.