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

From: Seth Blank <[email-masked]>
Date: Tue, 22 Jan 2019 10:08:41 -0800

Scott, does this need to be addressed during WGLC for draft-levine-eaiauth?

---------- Forwarded message ---------
From: Scott Kitterman <[email-masked]>
Date: Sun, Nov 4, 2018 at 9:14 PM
Subject: Re: [dmarc-ietf] Proposed charter spiff to accept EAI
clarification within email authentication stack
To: Kurt Andersen (b) <[email-masked]>
Cc: [email-masked] <[email-masked]>

On November 5, 2018 3:21:15 AM UTC, "Kurt Andersen (b)" <[email-masked]>
wrote:
>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-masked]
https://www.ietf.org/mailman/listinfo/dmarc

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 22 Jan 2019 11:17:19 -0800

I'm pretty sure charter adjustments are independent of WGLC (which is to
say don't hold up one with the other).

-MSK

On Tue, Jan 22, 2019 at 10:09 AM Seth Blank <[email-masked]> wrote:

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

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Tue, 22 Jan 2019 10:27:36 -1000

I think that Seth is referring to Scott's "merely" designation:

It doesn't appear that it proposes any changes for SPF.  It merely
> corner case not worth it to break the installed base over.

rather than the charter change itself. I did not read this as something
that needed to change in the document unless Scott is looking for bold
flashing lights around it :-)

--Kurt

On Tue, Jan 22, 2019 at 9:17 AM Murray S. Kucherawy <[email-masked]>
wrote:

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

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 22 Jan 2019 16:18:10 -0500

When I wrote that, several months ago, I was concerned there might be an 
incompatible update.  I don't see any problems with the draft as it currently 
stands, so no issue.  What's there describes things correctly.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 22 Jan 2019 16:19:28 -0500

For avoidance of doubt:

It's draft-ietf-dmarc-eaiauth and no.  It's fine.

Scott K

---

From: Seth Blank <[email-masked]>
Date: Wed, 23 Jan 2019 07:10:48 -0800

Excellent, thanks for the clarification.

On Tue, Jan 22, 2019 at 1:18 PM Scott Kitterman <[email-masked]>
wrote:

> > > During the SPFbis working group we looked at this and explicitly
> decided
> > > on
> > On Tue, Jan 22, 2019 at 9:17 AM Murray S. Kucherawy <[email-masked]
> >
> >
> > wrote: