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

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 29 Jan 2003 13:54:09 -0600

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:[email-masked]]
> Sent: Wednesday, January 29, 2003 1:29 PM
> To: John C Klensin
> Cc: [email-masked]; [email-masked]
> 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.

---

From: [email-masked]
Date: Wed, 29 Jan 2003 21:44:10 +0000

"Spencer Dawkins" <[email-masked]> writes:

> what's an obvious name for a working group PRUNING IMAP4?
> 

MAPLET -- Message Access Protocol Limited to Efficient Tasks?

-- 
David J. Aronson, Software Engineer for hire in Washington DC area.
See http://dja2001.home.att.net for online resume, references, etc.

---

From: [email-masked]
Date: Thu, 30 Jan 2003 01:50:35 +0000

"Spencer Dawkins" <[email-masked]> wrote:

> David, you're a genius!

Thanks.  Can I use you for a reference?  B-)  (See signature.)

> Glenn Parson told me he was VERY proud of the LEMONADE acronymn,

Yes, and now that I've gone and looked up what it is and all that (hey, I was 
away from IETF stuff for a long time, and VPIM/IVM even longer), I too am 
impressed.  Well done, Glenn!  That sure beats my Tonnage Overhead Reduction 
Protocol with Enhanced Depth Options, from back when this list was much 
chattier (and sillier) than it seems to be now.

See y'all on the UM list, which I just joined.

---

From: "Eric Burger" <[email-masked]>
Date: Thu, 30 Jan 2003 13:05:11 -0500

Executive Summary: Accept John's second proposal.  That is, take the charter as is, and insert a May 2003 deliverable of "lemonade Architecture, IESG and IETF Review, and Possible Rechartering".

Now that I'm clearing out my mailbox...

1) When I saw the flood of messages, and the nature of the objections, I wondered if anyone actually read the charter.  When I saw that a very old draft got posted, my faith in people was restored.

2) Pete - I'll take the fall for not posting the last revision for review.  There were about 4 changes from the last, publicly reviewed charter to the one submitted to the IESG in the last go round.  Each of those changes seemed minor (like what the acronym meant).  However, taken collectively, they are a larger leap.

Mea Culpa :-(

3) Initially, we were a bit leery about putting any changes to IMAP within the lemonade charter.  If we get more participation from the broader IMAP community, then I would be more comfortable with the idea.  That said, negotiable profiles do seem sensible.

4) Our original thoughts vis-a-vis IMAP was NOT to formally trim IMAP.  It was to (gulp) add a method for alternate retrieval (CHANNEL) and to have more relevant status information (e.g., media size).

5) For better or worse, lemonade has provided a forum (and one could say an impetus) for the discussion of some taboo topics.  For example, what started as a very limited scope need, server-to-server bulk notifications, has gotten people to actually WRITE the requirements, protocol issues, security issues, and privacy issues around notification in general.  This helps get the discussion out of the darkness of "doing that is bad, trust me; if you were knowledgeable you would understand" into the light of "read this paper - it explains the issues."  That alone is worth its weight in gold.

6) I have no problem narrowing the scope of the charter.  I have no problem expanding the text of the charter to more accurately reflect the scope (e.g., refine the language of bullet 4 to explicitly say "IMAP Profile").  I am leery of adding IMAPv5 or IMAPlite to the charter.  I really would like to the work group finish in a bounded time period.

7) As we are approaching our second year of BOF's and planning for the work of the WG, I think that we can make progress by taking John's second proposal.  In short, take the charter as is, and insert a May 2003 deliverable of "lemonade Architecture, IESG and IETF Review, and Possible Rechartering".  I would offer that starting with the architecture, instead of the requirements, would most likely result in a poor result.  We should push out the subsequent milestones appropriately, and mark them as tentative.

--
- Eric Burger
Co-chair, lemonade BOF

> From: John C Klensin [mailto:[email-masked]]
> Sent: Wednesday, January 29, 2003 5:01 PM
> To: [email-masked]; Pete Resnick
> --On Wednesday, 29 January, 2003 13:06 -0800 
> "[email-masked]" <[email-masked]> wrote:
> 
> >> I agree. And unfortunately, I think this is due to a serious
> >> problem about which I'm quite distressed:
> >
> >> The proposed charter contained in the announcement is *not*
> >> the proposed charter worked out on the LEMONADE BOF mailing
> >> list. Not even close. The one on the list went through
> >> several revisions to include specific language in the work
> >> items about profiling of existing protocols, and that
> >> language has been removed in what was posted here. The one on
> >> the list was tailored specifically to avoid having the
> >> working group add to existing protocols (with IMAP as only
> >> one example) unless absolutely necessary, but rather to
> >> profile existing protocols if that solved the problem. The
> >> present charter gives the incorrect impression that the
> >> desire of the group is simply to add extensions, specifically
> >> to IMAP.
> >
> > Well, as it happens the charter that was posted to
> > ietf-announce wasn't the one the IESG approved either. It is
> > one from quite a few versions back.
> >
> > I've attached the current charter below.
> 
> Ned, this one is _lots_ better.  I'll leave sorting out how the 
> wrong version got posted to the IESG and the Secretariat.  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.
> 
> If the community believes all that has been said in Atlanta and 
> on the "problem-statement" list about raising architectural 
> issues early in the life of a WG rather than hitting the WG 
> during Last Call (and you can be assured that several of us will 
> scream loudly if this WG emits large extensions to IMAP without 
> really clear justification), then charter-time is the time to 
> fix this one.  If the intent that all of us have is the same 
> --which I suspect to be the case-- then all that is needed is to 
> fix text to make that intent clear to the community and to WG 
> members who have not participated in the previous discussions. 
> That should be helpful for the Chair(s), for the ADs and for the 
> community.
> 
> >> First, a process point: If these significant changes were
> >> made by the IESG to what was submitted, these should have
> >> been brought back to the list for approval.
> >
> > I regard this as being up to the chair of the group. The
> > charter that wasn't posted was iterated on by both the chairs
> > and the IESG.
> 
> Then this is an objection to the textual form of the charter 
> version you posted as well as to the form the Secretariat 
> posted.  If the "extend IMAP" issues are settled, then let's get 
> that fact  documented in the charter to prevent later surprises 
> and unpleasantness.   If they are not, then let's either
> 
> 	* Hold a review of those issues by some body whose
> 	responsibility is to the Internet, and Internet mail,
> 	infrastructure is taken broadly, not just accomodating a
> 	few new capabilities.  Have that review before the WG is
> 	initiated, and make its conclusions binding on the WG.
> 	
> 	* Provide, in the charter, a community review point at
> 	the initiation of significant extension work on IMAP or
> 	anything else(were such work to be initiated), so that
> 	we don't get a pushback situation well into the 11th
> 	hour.
> 
> regards,
>     john
> 
> 
>