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.
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html