Re: [dmarc-ietf] Proposed charter spiff to accept EAI clarification within email authentication stack

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 <sklist@kitterman.com> wrote:

>
>
> On November 5, 2018 3:21:15 AM UTC, "Kurt Andersen (b)" <kboth@drkurt.com>
> wrote:
> >On Mon, Nov 5, 2018 at 10:11 AM Scott Kitterman <sklist@kitterman.com>
> >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
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>