I have no idea what the law of intended consequences might be or what
conclusions you might believe we should draw from it.
I dislike argument by aphorism. If something is worth saying it is worth saying
clearly.
________________________________
From: Michael Thomas [mailto:mike(_at_)mtcc(_dot_)com]
Sent: Wed 14/11/2007 2:53 PM
To: Hallam-Baker, Phillip
Cc: Eliot Lear; O'Reirdan, Michael; ietf-dkim(_at_)mipassoc(_dot_)org
Subject: Re: [ietf-dkim] Proposal to amend SSP draft with a
reportingaddress(fwd)
Well, this pretty much confirms my suspicions of the law of unintended
consequences, even if this a layer 8 example rather than a layer <= 7
example.
Mike, seeming simple proposals masking a huge undefined problem
Hallam-Baker, Phillip wrote:
I propose that there are the following requirements:
1) Mechanism for announcing that a service is available to accept
reports of DKIM verification failures
2) Mechanism for specifying which reporting protocols are supported
3) Mechanism for discovery of the reporting service of a given protocol
4) Specification of the reporting protocol
I regard 4 as being out of scope for DKIM, we should not develop a
protocol.
I regard 3 as being solved by DNS SRV, its what it is for
So that leaves 1 and 2. I consider these to be a DKIM responsibility,
in particular an SSP responsibility.
In an ideal world there would be an ideal reporting protocol. I don't
think that we are an ideal world and so I beleive that DKIM must
support some means of reporting protocol agility just like we would
regard protocol versioning a good thing.
The difference is not at all complicated, it means writing REPORT=ARF
or REPORT=ARF|INCH
There is a philosophical design issue here, clearly it is a bad thing
for DKIM to provide more options than is necessary to address DKIM
functions. But it is also a bad thing for DKIM to force the use of a
particular support infrastructure. This is why we made sure that we
can in fact use DKIM with XKMS or with X.509 pki even though we have a
key record mechanism.
I don't want to get into the design of the reporting protocol here. I
am not even sure that ARF is what a standard would look like, we
already have INCH after all. If we decide to design DKIM to only use
ARF we create a dependency and have to ensure that ARF is at
equivalent standards level. Weak coupling is what we need, provide a
slot to allow interaction with ARF but don't force a choice.
------------------------------------------------------------------------
*From:* Eliot Lear [mailto:lear(_at_)cisco(_dot_)com]
*Sent:* Wed 14/11/2007 10:37 AM
*To:* Hallam-Baker, Phillip
*Cc:* Damon; O'Reirdan, Michael; ietf-dkim(_at_)mipassoc(_dot_)org
*Subject:* Re: [ietf-dkim] Proposal to amend SSP draft with a
reportingaddress(fwd)
Hallam-Baker, Phillip wrote:
I am happy to say that DKIM MUST support the use of ARF as A
reporting format
I disagree that it should be the only reporting format supported.
What we want today and what we will want in five years time are going
to be different. ARF is a decent start but its limited. To go much
further it is going to be necessary to use structured data.
Ok, but let's proceed cautiously here, Phillip. This is an area where
more standards != better. How would you propose we manage
interoperability?
Eliot
------------------------------------------------------------------------
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html