For avoidance of doubt: It's draft-ietf-dmarc-eaiauth and no. It's fine.
Scott K On Tuesday, January 22, 2019 10:08:41 AM Seth Blank wrote: > Scott, does this need to be addressed during WGLC for draft-levine-eaiauth? > > ---------- Forwarded message --------- > From: Scott Kitterman <[email protected]> > 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 protected]> > Cc: [email protected] <[email protected]> > > > > > On November 5, 2018 3:21:15 AM UTC, "Kurt Andersen (b)" <[email protected]> > > 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 protected] > https://www.ietf.org/mailman/listinfo/dmarc _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
