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:[EMAIL PROTECTED] Sent: Wed 14/11/2007 2:53 PM To: Hallam-Baker, Phillip Cc: Eliot Lear; O'Reirdan, Michael; [email protected] 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:[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 >
_______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
