Hi, Pete,
I've been looking at the BOF announcements for LEMONADE previously,
and this wasn't the impression I had, at all. Thank you for clarifying.
The clarification makes it more obvious this may be the right thing to do.
But...
If this proposed working group is, indeed, trimming down IMAP4 (bravo!),
it seems wildly misnamed. The convention seems to be "(x)ext" for working
groups EXTENDING an existing protocol, but what's an obvious name for
a working group PRUNING IMAP4?
"minIMAP4rev1"? "IMAP4rev1minus"?...
Spencer
-----Original Message-----
From: Pete Resnick [mailto:presnick(_at_)qualcomm(_dot_)com]
Sent: Wednesday, January 29, 2003 1:29 PM
To: John C Klensin
Cc: ietf(_at_)ietf(_dot_)org; iesg(_at_)ietf(_dot_)org
Subject: Re: WG Review: Enhancements to Internet email to support
diverse service environments (lemonade)
On 1/29/03 at 1:40 PM -0500, John C Klensin wrote:
Now we have a WG proposal which seems to have a major theme of
adding more capabilities and options to IMAP
Before everyone ends up latching onto this: You quite conveniently
ignore something very important in the first statement of purpose in
the charter: "The goal is to provide a set of enhancements AND
PROFILES" (my emphasis). One of the major themes, at least in my
mind, is to profile down IMAP for the purposes of these more limited
environments. Yes, it is certainly true that there are a couple of
extensions to IMAP being proposed, and I don't doubt that they should
be met with scrutiny. (More on this in my earlier response to kre and
below.) But I think the more important thing for this group to do is
to find a way to avoid much of the huge complexity IMAP. One of the
sources of this complexity is that there are so many optional
extensions to IMAP that are implemented to such varying degrees by
servers (and with such huge impacts on functionality) that no client
has any reasonable chance of interoperating without being terribly
complex. One of the primary outcomes of this working group should be
a profile of IMAP that is devoid of options, that removes features
who's primary purpose is to support particular implementations
choices at the expense of interoperability, and gives folks in
low-capability environments a chance to produce a decent
implementation.
If this is what you mean by "IMAP Lite", I would contend that this is
the architectural choice that this particular proposed WG has made.
I think there should be a great deal of pressure on this group to
*not* bloat IMAP, and in fact rather to shrink it. However, there is
nothing in the proposed charter (or in the mind of this particular
member of that proposed WG) that should give you the impression that
the intention is otherwise.