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: > > [email protected] 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<[email protected]> >> To: DKIM IETF WG<[email protected]> >> 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
