[ietf-dkim] Why bother removing features?

[Eliot Lear]

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.Oxley at cox.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.net>
>> To: DKIM IETF WG<ietf-dkim at mipassoc.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.
>>      
>
>
>
>