ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Issue 1550 - the name of the document (remains open *briefly*); there's still,disagreement on "Author"

2008-03-13 00:13:37
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 
opposition.

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.

-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

<Prev in Thread] Current Thread [Next in Thread>