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:[EMAIL PROTECTED] Sent: Wed 14/11/2007 10:37 AM To: Hallam-Baker, Phillip Cc: Damon; O'Reirdan, Michael; [email protected] 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
