> 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?
THat's a good point. However, I have to say that while it would be nice in
theory to include information about whatever conditional scheme ends up getting
standardized in this document and/or what's in deployed code, deferring this
document in order to make that possible isn't really feasible from a process
standpoint.
Ned
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
