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

[Scott Kitterman <[e-mail]>]

On November 5, 2018 3:21:15 AM UTC, "Kurt Andersen (b)" <[e-mail]> wrote:
>On Mon, Nov 5, 2018 at 10:11 AM Scott Kitterman <[e-mail]>
>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