Hallam-Baker, Phillip wrote:
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.
Ok. This is spinning rapidly out of control and far, far away from what
we agreed were the requirements for the protocol.
Mike
------------------------------------------------------------------------
*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