So what are the real pro's and con's between monolithic protocol vs multiple task-specific protocols? And is that the real limitation in terms of 'richness' that we are seeing here?
Advantages of monolith over multiple (all of this is my two cents):
A monolith doesn't have the problems of scope, of course. Its scope is everything.
A monolith has fewer version mismatch problems, or availability problems. Either the server is up or it's down. When it's upgraded, everything is. No need for a client to handle the case of IMAP being available but the SMTP smarthost not if the same TCP connection to the same server provides everything.
A monolith has easier authentication, in most cases. Single sign-on, all done.
The monoliths that have been mentioned all are single-company protocols, where the company can react fairly quickly to add new features. (OTOH, many such new features can interoperate badly with the rest of the world. http://www.exchangefaq.org/outlook/0002.php3 shows one well-known problem.)
Disadvantages:
It's very hard to implement all of a monolith for v1.0 of some program, and if they're not all implemented, the mismatch/availability problems appear.
Of the monoliths that have been discussed, most simply aren't documented, which is a massive disadvantage for a prospective implementor and significant also for consultants and sysadmins. (I know X.400 is documented, but I'm not willing to bet the documentation is very lucid, or available to random sysadmins.)
The monoliths that have been discussed seem to force the use of a single client, restricting the users' future choice of vendor, OS and hardware. (Unless there are still two X.400 clients on the market?)
It would be extremely difficult to document a monolith up to typical RFC standards. Imagine getting a five-thousand-page RFC out.
--Arnt
