I think MSK’s text with Kitterman’s caveat cleanly carved out for interoperability regressions is the optimal charter update.
On Mon, Nov 5, 2018 at 00:14 Scott Kitterman <[email protected]> wrote: > > > On November 5, 2018 3:21:15 AM UTC, "Kurt Andersen (b)" <[email protected]> > wrote: > >On Mon, Nov 5, 2018 at 10:11 AM Scott Kitterman <[email protected]> > >wrote: > > > >> On Monday, November 05, 2018 10:01:03 AM Kurt Andersen wrote: > >> > I think that we could possibly already read this into the existing > >> charter, > >> > but the following one sentence patch makes it explicit: > >> > > >> > diff --git a/dmarc-wg-charter b/dmarc-wg-charter > >> > index a1d0fac..c8ac6bc 100644 > >> > --- a/dmarc-wg-charter > >> > +++ b/dmarc-wg-charter > >> > @@ -81,6 +81,9 @@ the working group can consider extending the base > >DMARC > >> > specification > >> > to accommodate such a standard, should it be developed during the > >> > life of this working group. > >> > > >> > +Clarifying the handling of internationalized email addresses (EAI) > >> > +throughout the authentication stack of SPF, DKIM, and DMARC. > >> > + > >> > Improvements in DMARC features (identifier alignment, reporting, > >> > policy preferences) will be considered, such as: > >> > > >> > --Kurt > >> > >> I don't see anything about changes to SPF or DKIM being within the > >current > >> charter, so if we are going to do this, then I think it definitely > >needs a > >> charter change. > >> > >> What needs changing in SPF/DKIM that we need to take this on? > >> > > > >This came out of this morning's DISPATCH meeting at IETF103 ( > >https://tools.ietf.org/wg/dispatch/agenda) to be able to accept > >http://tools.ietf.org/html?draft=draft-levine-appsarea-eaiauth into the > >WG > >for advancing it to an RFC (probably informational). > > Thanks. It doesn't appear that it proposes any changes for SPF. It > merely documents that non-ascii local parts don't match the related > macros. During the SPFbis working group we looked at this and explicitly > decided on it. It's not by accident. > > Since local part macros are very rarely used, it seemed like very much a > corner case not worth it to break the installed base over. > > If there's going to be a charter change around this, I think it needs some > words to constrain the work to limit interoperability implications. > > I know less about the implications for DKIM and DMARC, but would imagine > backward compatibility is important there too. > > Scott K > > _______________________________________________ > dmarc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
