ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Why bother removing features?

2009-06-12 20:48:35

On Jun 12, 2009, at 6:34 AM, <Bill(_dot_)Oxley(_at_)cox(_dot_)com> 
<Bill(_dot_)Oxley(_at_)cox(_dot_)com>  
wrote:

Okay, I would like to keep what we have, removing pieces is not a  
good idea, people don't have to use the tags if they don't want to

Implementors have to, for DKIM verifiers at least. Also, even DKIM  
signers have to either understand the semantics of each and every tag,  
even if they don't use them, or ignore the spec and use a subset of  
possible configurations as advised by a third-party deployment document.

and we MAY have a need for them in the future.

We may. Verifiers will need to support them pretty much forever  
whether we do or not, though. Also, in the case where the actual use  
of the flag is as part of an extension then there will need to be  
standards making and new development to actually use the flag, whether  
it's in the base spec or not.

The tags were discussed at length during the original draft.  
Removing them after the fact doesn't help or hurt adoption rates.

I've seen interop problems caused very recently by a deep  
misunderstanding of what g= is for and how it interacts with i=. "We  
tried DKIM and gmail / yahoo said our signatures were invalid" is  
hurting adoption by senders today, and I'm sure some of that is  
because of misunderstanding of what some of the more obscure flags are  
supposed to be used for.

Which subset of tags could be pruned (or even whether that's a zero  
size set) is a good question, but some of them are causing hurt today.

Cheers,
   Steve



-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org 
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org 
] On Behalf Of Barry Leiba
Sent: Thursday, June 11, 2009 3:46 PM
To: ietf-dkim(_at_)mipassoc(_dot_)org
Subject: Re: [ietf-dkim] Why bother removing features?

Come on, people: stop being snarky.
Dave asked a legitimate question about the DKIM base spec, which has
been Proposed Standard for two years now, and which we're considering
progressing to Draft Standard.

Whether you like ADSP or not, it isn't part of this.

Barry
_______________________________________________
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

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