> 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
