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
