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