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

> -----Original Message-----
> From: John C Klensin [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, January 29, 2003 5:01 PM
> To: [EMAIL PROTECTED]; Pete Resnick
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: WG Review: Enhancements to Internet email to support
> diverse service environments (lemonade)
> 
> 
> 
> 
> --On Wednesday, 29 January, 2003 13:06 -0800 
> "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> 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
> 
> 
> 

Reply via email to