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 On Tuesday, January 22, 2019 10:27:36 AM Kurt Andersen wrote: > I think that Seth is referring to Scott's "merely" designation: > > 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. > > 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 protected]> > > wrote: > > 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 protected]> 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 > > > > _______________________________________________ > > dmarc mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/dmarc _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
