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

And beyond what Dave said, if a feature is unused you can't take it to 
draft.

Eliot

On 6/13/09 1:51 PM, Dave CROCKER wrote:
> 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 and we MAY have a
> > need for them in the future.
> >      
> There is an infinite array of features that we may have need for in the 
> future.
>    So that's not an encouraging line of argument for retaining any particular
> feature.
>
> Features carry costs.
>
> Perhaps you missed my earlier note, which touches on the significant costs of
> retaining unused features:
>
>
>    
> > Date: Thu, 11 Jun 2009 12:29:56 +0200
> > From: Dave CROCKER<dhc(_at_)dcrocker(_dot_)net>
> > To: DKIM IETF WG<ietf-dkim(_at_)mipassoc(_dot_)org>
> > Subject: [ietf-dkim] Why bother removing features?
> >
> >      
> ...
>    
> > The problem with retaining unused features is that it makes it more 
> > difficult to
> > explain DKIM use, it adds to the cost of developing DKIM support, and it 
> > invites
> > interoperability problems later.
> >
> >
> > 1.  Explaining things
> >
> > Since we are still seeking adoption by more email services, we still have a
> > significant education task to perform.  This is both about the nature of DKIM
> > and the particulars of using it.  And it is both for developers and for
> > operators.  The latter especially need not just the value proposition but the
> > operational impact, which means discussion of usage scenarios.
> >
> > The more features in a protocol, the more difficult it is to explain how 
> > things
> > work, due to combinatorial interactions.  Phrases like "use it however you 
> > want"
> > do not help because operations folk need to be told the answer, not assigned 
> > the
> > task of developing one.
> >
> > At its core, DKIM is really rather simple:  Give the receiver a validated
> > identifier that asserts a degree of responsibility for a message.  The
> > validation is accomplished by signing the message body and some of the header
> > fields.  The public key is in the DNS.  Done.
> >
> > With its full set of additional features, DKIM's nature becomes potentially
> > confusing and its operational use even more so.
> >
> >
> > 2.  Unused feature are costly
> >
> > Actually, of course, /all/ features are costly.  There is no such thing as an
> > additional feature that is entirely free.  Each feature requires coding, 
> > testing
> > (internally and with other implementations), documenting and (potentially)
> > operations and support.  Unused features have the distinctive characteristic 
> > of
> > developing no serious operational experience, so that the basis for 
> > documenting
> > use is poor.  This leads to the next concern...
> >
> >
> > 3.  Unused features invite interoperability problems long after initial 
> > adoption
> >
> > Unused feature are like time-bombs.  No matter how diligent developers are, 
> > the
> > usual interoperability shake-out for protocol code won't happen, because 
> > some of
> > this requires real-world use.  So when (if) use finally starts happening, 
> > there
> > is certain to be a round of interoperability problems.  Having this occur 
> > long
> > after DKIM is adopted winds up making DKIM look unstable/unreliable.  Just 
> > the
> > sort of thing one does not want ever, but especially for a security feature
> > primarily targeted at email operations.
> >
> > So, tight specifications that have only the core features, known to be 
> > needed,
> > benefit from being easier to explain, cheaper to deploy and operate and 
> > safer in
> > the long-run.
> >      
>
>
>    
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html