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:
The decision to retain the feature seems to come from the view that the current
cost of keeping it will be low and the cost of removing later will be low.
I believe both assessments are incorrect.
Keeping a questionable feature carries a significant cost: Each feature is an
incremental barrier to adoption, both in terms of development
effort and in terms of testing and certification effort. Worse, the aggregate
effect of a set of features seems to have a non-linear impact, so the increments
-- after the first few features -- are not small.
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.
(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