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
