ietf
[Top] [All Lists]

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

2003-01-29 13:51:37
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.