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

From: Shawn Steele <[email-masked]>
Date: Thu, 4 Aug 2016 19:48:17 +0000

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’m clearly missing something & granted I didn’t spend all day reading it, but how is this not a “yes, my spam list has good addresses!” feature?

- Shawn

 
http://blogs.msdn.com/shawnste<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fblogs.msdn.com%2fshawnste&data=01%7c01%7cShawn.Steele%40microsoft.com%7c84e9a7e949424607aa7e08d2db1af438%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=7geUWqk26QXcuTobmofsuVAMCFnVv5BRPLT2rnQBSM4%3d>
http://bb-8.blogspot.com<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fbb-8.blogspot.com&data=01%7c01%7cShawn.Steele%40microsoft.com%7c84e9a7e949424607aa7e08d2db1af438%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=o2r6e84vcXvjOiNkmJPU095fbyOIdFTetYocZzqXQu8%3d>

---

From: John C Klensin <[email-masked]>
Date: Thu, 04 Aug 2016 16:27:45 -0400

Shawn,

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
<[email-masked]> 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

to

   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.

>...

best,
   john

---

From: Shawn Steele <[email-masked]>
Date: Thu, 4 Aug 2016 21:05:59 +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.

-Shawn

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

Shawn,

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 <[email-masked]> 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:
> 
> 
> dependent on other new things.  Such as depending on UTF8SMTP instead 
> of designing other mechanisms for non-ASCII content.

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

to

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.

best,
   john

---

From: John C Klensin <[email-masked]>
Date: Thu, 04 Aug 2016 18:20:29 -0400

--On Thursday, August 04, 2016 21:05 +0000 Shawn Steele
<[email-masked]> wrote:

> 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.

Completely agree, modulo working out a plan that doesn't
immediately make the vast majority of existing implementations
non-conformant... or a community decision that is the best way
to go anyway.  Just wanted to be sure we were talking about the
same thing, which we appear to be.

best,
   john

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Sun, 7 Aug 2016 16:42:51 +0400

How about noncommittal wording that leaves the option of using 8bit cte 
open, suggests doing that for smtputf8 and notes that there may still 
be software around that has problems with it so perhaps avoid in other 
cases? No MUST anywhere and it had a touch of realism.

Arnt