--On Thursday, 30 January, 2003 13:56 -0800 Randall Gellens
<randy(_at_)qualcomm(_dot_)com> wrote:
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.
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.
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