This really isn't worth much discussion unless someone is really going to launch such an effort, but I don't see the distinction as clearly as you do. We already have a situation in which some clients won't interoperate well with some servers because the clients think they need certain capabilities that those servers don't support. And we have other server authors that have refused to implement certain features because they (the authors) are convinced those features are brain-damaged. I'd like to see a WG give careful consideration to the question of the damage that would be done by pulling commands and replacing them with better/ cleaner designs as well as the type of revision I think you anticipate with the first case.This raises an interesting point that may be in danger of being obscured. I think there is general agreement that IMAP is too complex. However, concepts such as "IMAP lite" (or even "IMAP light"), simplification, pruning, etc. can be understood in very different ways. It could mean simplifying interoperability by reducing options and eliminating permitted behavioral differences (especially among servers). It could also mean taking out commands and responses. The former can be accomplished in an interoperable way; a new IMAP revision or capability could be defined which includes a number of previous options, and specifies varies behavioral aspects (along the lines of RFC 1123). Clients written to previous versions of IMAP would be able to interoperate with a new server just fine. The latter, while making the protocol simpler and easier to understand and implement, risks being non-interoperable with previous versions.
But, in the last analysis, IMAP4bis is still at Proposed. Like you, I'd prefer something easier to implement and deploy that is fully compatible with IMAP4bis. But, if that isn't possible, then I think it would be rational to consider other alternatives, with the understanding that some implementations would try to be conforming to both the older and newer versions and that it would be wise to design things so as to make that possible.
john
