On 11/10/2015 12:40 PM, Terry Zink wrote:
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
I agree with Terry on this, mainly because of the implementation issue
for receivers.
-----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
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
