On Tue, May 17, 2016 at 5:46 PM, Dave Crocker <dcroc...@gmail.com> wrote:
> Relevant charter text: > > The working group will explore possible updates and extensions to the >>> specifications in order to address limitations and/or add >>> capabilities. >>> >> ... >> >>> Specifications produced by the working group >>> >> ... >> >>> 1. Addressing the issues with indirect mail flows >>> >>> The working group will specify mechanisms for reducing or eliminating >>> the DMARC's effects on indirect mail flows, including deployed >>> behaviors of many different intermediaries, such as mailing list >>> managers, automated mailbox forwarding services, and MTAs that >>> perform enhanced message handling that results in message >>> modification. Among the choices for addressing these issues are: >>> >>> - A form of DKIM signature that is better able to survive transit >>> through intermediaries. >>> >>> - Collaborative or passive transitive mechanisms that enable an >>> intermediary to participate in the trust sequence, propagating >>> authentication directly or reporting its results. >>> >> >> as against: >> >> 2. Reviewing and improving the base DMARC specification >>> >>> The working group will not develop additional mail authentication >>> technologies, but may document authentication requirements that are >>> desirable. >>> >> > > Any interesting topic produces real challenges in charter-writing and even > more challenges in charter-reading. > Indeed, I've yet to encounter a perfect charter. > However I read Item 1 as exactly matching the issue at hand and I read > that text as being unambiguously perfect for the specific proposal at > hand. (Hint: this was not an accident.) > > The current topic has nothing to do with Item 2, which is where the > constraint is placed. So the constraint is not relevant for the current > topic. > That feels like a convenient interpretation to me, for two reasons: 1) It feels like a bit of a stretch to call ARC "a form of DKIM signature", so I have to assume ARC falls under the second bullet. 2) The section of the charter you cite enumerates three "tracks', which it later calls "phases". If we're done with the first phase by sending our sole document to the IESG (which has happened, and the chairs have explicitly declared phase one done), then we appear to have entered a phase for which the charter proscribes things like ARC. > Yes, one certainly could wish for better writing. Sorry about that. But > really... I'm not opposed to developing ARC within this WG or even within the IETF. I just want to make sure we're following our own rules here, and that someone who later decides he hates ARC has no basis to appeal. If this needs fixing, let's fix it. If nobody really cares, let's move on. -MSK
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
