[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: WG Review: Enhancements to Internet email to support diverse service environments (lemonade)
At 5:01 PM -0500 1/29/03, John C Klensin wrote:
But my primary concern (and one of those on which Pete and I are
apparently in agreement) remains: when I read "enhance...IMAP", I
don't infer "narrow the protocol for use in this environment" or
"specify a way to use the existing protocol to accomodate these
needs". Instead, I infer "new feature", "new capability", and
"putting more stuff into the protocol". I think there is
considerable resistance in the community to making IMAP bigger --
while the four messages that have shown up on the list are not much
of a sample, I observe that at least three of them have included
"make it smaller, not larger" positions.
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.
--
Randall Gellens
Opinions are personal; facts are suspect; I speak for myself only
-------------- Randomly-selected tag: ---------------
A server is only as secure as its dumbest administrator
--Steve Dorner