RE: WG Review: Enhancements to Internet email to support diverse service environments (lemonade)

["Spencer Dawkins" <sdawkins@cynetanetworks.com>]

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@qualcomm.com]
> Sent: Wednesday, January 29, 2003 1:29 PM
> To: John C Klensin
> Cc: ietf@ietf.org; iesg@ietf.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.