[ietf-dkim] Issue 1550 - the name of the document (remains open *briefly*); there's still,disagreement on "Author"
hsantos at santronics.com
Wed Mar 12 23:26:50 PDT 2008
Mark Delany wrote:
> On Mar 12, 2008, at 8:20 PM, John Levine wrote:
>>> Hello? Why? You mean it's out of line for me to point out that
>>> people might not have appreciated the full implications of what they
>>> were arguing about?
>> Based on the discussion I listened to in the DKIM session, I am
>> confident that people who proposed changing the name of SSP are fully
>> aware that slightly more than zero effort would be required to change
>> record names from _ssp to _frodo or whatever, and perhaps even a
>> slight additional amount of effort would be needed to publish and
>> check both old and new names for a few weeks while people catch up.
> Might I also add that we agreed to a totally incompatible change from
> DomainKeys to DKIM in the interest of harmonizing the final standard
> even though the *installed based* was/is quite large.
> In that light, I'm interested in understanding why breaking
> DomainKeys for non-technical reasons was ok, yet breaking an _ssp
> draft with a relatively miniscule adoption rate is less than ok.
> Put another way, we had a bunch of working code that the IETF threw
> away. Why is our working code less important that the _ssp working code?
And to add to the chaos,
There are two open source API, sendmail's mfilter DKIM/SSP API and
ALTN's fine windows DKIM/SSP library. Even Arvel somewhere in within
the source code or read me file indicated some level of confidence in
the stability with SSP-01 and he believed, including myself, there would
little technical changes from this point on. It with this level of
understanding, in what is otherwise is otherwise a very complex and
costly implementation effort, that we began take the system more serious.
This SSP work represented over 2 years work in the WG and we had finally
come to some level of understanding for SSP.
No one expected such a complete breakdown and take over by the ASP
members, people, I don't mind saying, NEVER, absolutely NEVER had any
belief in SSP since the git-go.
But all of sudden, just when it appeared we were at some technical
comfort level for serious DKIM support, including beginning prpduct
marketing efforts and promoting it with our customer base, BANG, it was
throw out and replaced with a NON-VETTED proposal by people who have
have an unfortunate propensity to shut out, shut up, block out any
Whatever was right or wrong, if ASP made any sense whatsoever, that
would be one thing, but it doesn't. Its terrible and how it was done
leave a bitter taste on the IETF process with the chairs beaten down and
forced to allow it to happen. The fact that SSP assimilate what was
essentially borderline plagiarized stripped down version, shocked common
sense and ethics.
On a related note, just consider this Deployment Draft statement that
when a receiver system does not have an Reputation process in place, it
SHOULD view signed mail as unsigned. Go Figure. It boggles the mind.
In any case, with the offline cursing email at me by a certain member of
the ASP group and the complete take over of this WG by ASP group I'm
sorry to say, but I wouldn't be true to myself if I didn't say you ASP
people should be ashame of yourselves.
Hector Santos, CTO
More information about the ietf-dkim