The decision from the jabber meeting was to keep it, thinking that we
could drop it later if it turns out not to be used. Paul correctly
points out that we could just as well drop it, and put it in later if it
turns out to be needed.
I had debated whether to make the following point, upon reading the jabber log,
so I'm happy it came up on its own:
Keeping a questionable feature carries a significant cost, without the attendant
benefit that one would like:
Each feature serves as an incremental barrier to adoption, both in terms of
development effort and in terms of testing and certification effort. Worse,
after the first few features, each additional feature's incremental cost is
larger than the one before. In other words the aggregate cost seems to be
something like exponential, combinatorial or the like.
In reality, it is far easier to later add features that are later deemed
required, than it is to later drop features that are initially deemed
questionable.
In other words: If we do not have a strong consensus that a feature is required
for the initial release of DKIM, we really ought to drop it.
(This, of course, is all in the classic spirit of good system design that looks
for what can be removed, rather than what can be added.)
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html