> OTOH, conditional signatures have been discussed for more than five years (my > dkim-joint-sigs I-D was in 2010), an implementation exists, albeit alpha > (Murray's OpenDKIM 2.11.0), and we seem to have a candidate WG document > (John's > dkim-conditional-02) which would match the charter's "form of DKIM signature > that is better able to survive transit through intermediaries". Can the WG > coordinate publication of these two I-Ds?
-1. Not because I don't think conditional DKIM can't work, but that we need to focus on one solution. When someone asks "How do I get email to survive DMARC if forwarded" we tell them "Go do this one thing" and not "Go do either this *or* this." It's also easier for receivers to implement, debug, and maintain one solution rather than two. -- Terry -----Original Message----- From: dmarc [mailto:[email protected]] On Behalf Of Alessandro Vesely Sent: Tuesday, November 10, 2015 4:02 AM To: [email protected]; Murray S. Kucherawy Cc: [email protected]; Franck Martin Subject: Re: [dmarc-ietf] Responses to comments on draft-ietf-dmarc-interoperability-08.txt On Mon 09/Nov/2015 23:16:42 +0100 ned+dmarc wrote: >> On Fri, Nov 6, 2015 at 1:37 PM, Franck Martin wrote: > >>> While the I-D will likely expires they will not be removed from the >>> website, so references will still work, so I don't see as that bad that >>> they are properly referenced in this document. I however agree we should >>> provide a quick summary for people that do not need the details. >>> > >> On the flipside, I don't see what value they add; the ones that gain >> consensus will be published in their own right, and the details of the ones >> that don't probably aren't interesting to later readers anyway. > > Generally speaking IETF Consensus/Publication != Adoption and Use. There are a > number of drafts that never made it to RFC that contain information on stuff > that did in fact deploy. (Although the best example of this by far is > actually > in X.400, where one of the most widely used text bodypart types was only ever > described in a preliminary draft.) > > That said, I'm dubious of the value of this section in a more general sense, > since in-progress work is likely to shift and change in unexpected ways, > which could easily make any description we provide more confusing than not. Somewhat agree, unless we're able to say more on the reasons why a specific approach failed to get broad consensus/ adoption. I'm thinking of RFC6541, for which the text in -10 (of the transient nature of I-Ds) doesn't hold. OTOH, conditional signatures have been discussed for more than five years (my dkim-joint-sigs I-D was in 2010), an implementation exists, albeit alpha (Murray's OpenDKIM 2.11.0), and we seem to have a candidate WG document (John's dkim-conditional-02) which would match the charter's "form of DKIM signature that is better able to survive transit through intermediaries". Can the WG coordinate publication of these two I-Ds? > I personally would prefer to limit this sort of thing to descriptions of > things we know are currently deployed to some degree. It's then up to > future work to describe it's own interoperability issues, which is going > to be a requirement for anything that makes it to RFC status anyhow. > > And yes, this does leave the door open for something that doesn't make it to > RFC but does achieve some degree of deployment. But I think we have enough > current issues to cover without trying to detail the nature of future ones. I'm neutral on mentioning ARC, dkim-transform, and dkim-canon-list. Ale _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
