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