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

From: Robert Elz <[email-masked]>
Date: Wed, 29 Jan 2003 18:13:27 +0700

Date:        Tue, 28 Jan 2003 18:12:05 -0500
    From:        Jacqueline Hargest <[email-masked]>
    Message-ID:  <[email-masked]>

  | A new IETF working group has been proposed in the Applications Area. 
[...]
  | Enhancements to Internet email to support diverse service environments
  | (lemonade)

  | 1.  An informational RFC will be produced on LEMONADE requiremens.

Fine.

  | 2.  Enhance the existing IMAP4 message retrieval protocol to satisfy
  |     the requirements for streaming playback of multimedia content.

What a horrid idea?   How do "streaming playback" and "message retrieval"
possibly fit together at all?   Is this yet another attempt to pervert
a protocol into meeting some other quite unrelated need, for the sole
purpose of getting through firewalls or similar?   Drop this nonsense.

  | 3.  Enhance the exsiting IMAP4 message retrieval protocol to facilitate
  |     its use with devices that have limited capabilities such as mobile
  |     endpoints.

Fine.

  | 3.  Create a message notification protocol for the specific purpose of
  |     servers reporting message status information to other servers.

A second #3 ...   This one looks more like a proposal for a solution,
than a work item.   If the solution is already known, a WG isn't needed,
just publish it.   Otherwise, indicate what problem needs to be solved,
for which this might be one solution, and see what alternatives are
offered.

  | 4.  Create a specification describing the use of Internet message
  |     services in environments where message delivery may take place
  |     using either Internet protocols or external protocols such as SMS.

Fine.

kre

---

From: John C Klensin <[email-masked]>
Date: Wed, 29 Jan 2003 13:40:08 -0500

--On Tuesday, 28 January, 2003 18:12 -0500 Jacqueline Hargest 
<[email-masked]> wrote:

> A new IETF working group has been proposed in the Applications
> Area.  The IESG has not made any determination as yet.
>
> The following description was submitted, and is provided for
> informational purposes only.
>
>
> Enhancements to Internet email to support diverse service
> environments (lemonade)
> --------------------------------------------------------------
> ----
>
> Current Status: Proposed Working Group
>
> Description of Working Group:
>
> Lemonade brings together a body of work related to Internet
> messaging, in particular work done by the VPIM, FAX, IMAPEXT<
> and other IETF working groups. The goal is to provide a set of
> enhancements and profiles of Internet email submission,
> transport, and retrieval protocols to facilitate operation in
> environments which use Internet-based technologies but which
> have link characteristics, device characteristics, or service
> environments that are significantly different from those
> common on the Internet.  A primary goal of this work is to
> ensure that those profiles and enhancements continue to
> interoperate with the existing Internet email protocols in use
> on the Internet, so that these environments and more
> traditional Internet users have access to a seamless service.
>...

Hi.

I'm finding this proposal deeply troubling and have been 
wondering whether to speak up.  Kre's note convinced me that I 
should.

There is a rather fundamental architectural question underlying 
this proposal.  The proposed charter assumes a particular answer 
to that question.  I believe that the community has reviewed the 
general question on a number of occasions and that it has 
usually come to the opposite answer.  It would be good, I think, 
to address that architectural question seriously in this case 
and to be sure that the solution-set proposed is the one we 
want.  And I don't think that can be done by a WG, or proto-WG, 
that is anxious to charge ahead on a particular path: I think it 
has to be an IAB or IESG task, or one delegated by them and 
responsible to them.

Details:  It has long been the conventional wisdom in the 
community that protocols that are low-complexity and that have 
few options will generally deploy more rapidly and widely, 
interwork better, and cause fewer problems than protocols that 
are highly complex in operation or that have very extensive or 
complex combinations of options and variations.  We have 
believed that principle strongly enough to include it explicitly 
in a number of Standard-level protocol documents (e.g., see the 
introduction to STD10/RFC1869), so there is reason to assume 
community consensus about it.   It has also been the 
conventional wisdom, backed by considerable bad experience, that 
adding functionality that is not obviously relevant to a 
protocol, simply because that protocol is there and available, 
is not a good idea.

It is widely believed that IMAP is already too complex, that it 
has too many options and variations, and that those factors have 
contributed to a shortage of implementations.  While it is hard 
to quantify that belief in protocol terms, it has often been 
observed that there are many implementations of POP3 servers 
that are suitable for use on home or small business servers. 
While there are a number of IMAP implementations that are 
suitable for enterprise use, with multiple server complexes and 
dedicated and/or expert support staff, estimates of the number 
of conforming servers suitable for SOHO situations and with any 
conforming client range between zero and one.  That is not a 
good situation, and there have been discussions within the IETF 
about starting "IMAP lite" efforts.

Now we have a WG proposal which seems to have a major theme of 
adding more capabilities and options to IMAP, including some 
capabilities (like streaming) that are not obviously connected 
with IMAP's core purpose or definition.  Architecturally, there 
are many other options for accomodating those capabilities, 
including designing a multi-protocol framework that would permit 
specialized protocols for streaming to interwork well with IMAP 
but without adding significant complexity or options to IMAP 
itself.  I am not sure whether one of those approaches would be 
better than proposals for additional IMAP capabilities.  But I 
believe that we should address those possibilities --and the 
costs of add more bulk and complexity to IMAP-- in a serious way 
before launching a WG to figure out how to put these things into 
IMAP.

As part of that effort, I think we should make a definite 
decision about the "IMAP Lite" discussions. If we want, or need, 
to move in that direction, than "IMAP-even-bigger" is not 
rational; if "IMAP Lite" would be a good idea (or is necessary 
to get serious deployment), then a proposal like this one is 
nearly incomprehensible.

     john

---

From: Pete Resnick <[email-masked]>
Date: Wed, 29 Jan 2003 12:45:12 -0600

On 1/29/03 at 6:13 PM +0700, Robert Elz wrote:

>>A new IETF working group has been proposed in the Applications Area.
>[...]
>>2.  Enhance the existing IMAP4 message retrieval protocol to 
>>satisfy the requirements for streaming playback of multimedia 
>>content.
>
>What a horrid idea?   How do "streaming playback" and "message 
>retrieval" possibly fit together at all?   Is this yet another 
>attempt to pervert a protocol into meeting some other quite 
>unrelated need, for the sole purpose of getting through firewalls or 
>similar?

No, that's not what this means. Actually, it's probably just the 
opposite of what you fear. For example, let's say you have some data 
in a message store which is a nice long hunk of sound. Instead of 
using IMAP to download the entire sound in order to play it, it might 
be much more intelligent to use an RTSP client to receive the data 
and play it directly. The envisioned mechanism would make it possible 
for the client to ask the server, "Can I get this back via RTSP, and 
if so, where do I connect up?" and the server can tell the client how 
to retrieve it.

>>3.  Create a message notification protocol for the specific purpose 
>>of servers reporting message status information to other servers.
>
>A second #3 ...

A typo.

>This one looks more like a proposal for a solution, than a work 
>item. If the solution is already known, a WG isn't needed, just 
>publish it. Otherwise, indicate what problem needs to be solved, for 
>which this might be one solution, and see what alternatives are 
>offered.

The solution is not known. The problem is that there is currently no 
standard mechanism for mail servers to announce the existence of new 
mail. Current protocols rely on polling or a constant connection to 
the mail server. The work item is to come up with a protocol that 
does notifications. Does the above not describe that work item 
appropriately?

pr
-- 
Pete Resnick <mailto:[email-masked]>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

---

From: Pete Resnick <[email-masked]>
Date: Wed, 29 Jan 2003 13:28:32 -0600

On 1/29/03 at 1:40 PM -0500, John C Klensin wrote:

>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.

>including some capabilities (like streaming) that are not obviously 
>connected with IMAP's core purpose or definition.  Architecturally, 
>there are many other options for accomodating those capabilities, 
>specialized protocols for streaming to interwork well with IMAP but 
>without adding significant complexity or options to IMAP itself.

If I understand you correctly, at least one of the proposals on the 
table (CHANNEL) does exactly this kind of thing: Instead of providing 
some sort of specialized streaming in IMAP, it instead introduces a 
referral mechanism, where a client can ask the server for a referral 
to a different protocol to stream the data. Whether this is a good 
idea or not can be debated, but this particular item is not an 
example of bloating IMAP with wild new features.

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.

pr

---

From: John C Klensin <[email-masked]>
Date: Wed, 29 Jan 2003 15:06:22 -0500

--On Wednesday, 29 January, 2003 13:28 -0600 Pete Resnick 
<[email-masked]> 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.
>...

But, Pete, for reasons you presumably understand, "profiles" 
(note plural) gives me as much anxiety as "lets add lots more 
excrement to this protocol".  Granted that it would be harder to 
make a complete mess of a mail-retrieval protocol than of a 
transport one, but "we will develop a minimal profile for this 
specific/ limited environment" and then "we will develop a 
minimal profile for that other specific/ limited environment" 
are the traditional signposts along the route to profiles that 
don't interoperate and a need to reply to email by picking up 
the phone.

> 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.)

One of them is potentially very heavyweight.  As you point out, 
there are other solutions to it, but the charter doesn't appear 
to prevent the WG from inventing some wildly new, and complex, 
way to handle the issue.    If it has already been decided that 
the WG won't go down that path, then the charter should say so. 
If it has been agreed that the WG isn't going to do that unless 
it turns out to be absolutely necessary, then the decision point 
about "absolutely necessary", and another opportunity for 
community review if it is determined to be necessary, should be 
reflected in the milestones.

> 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

Well, we agree, but it is hard to figure that out from the draft 
charter.

> 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.

See below.

>> including some capabilities (like streaming) that are not
>> obviously  connected with IMAP's core purpose or definition.
>> Architecturally,  there are many other options for
>> accomodating those capabilities,  including designing a
>> multi-protocol framework that would permit  specialized
>> protocols for streaming to interwork well with IMAP but
> If I understand you correctly, at least one of the proposals
> on the table (CHANNEL) does exactly this kind of thing:
> Instead of providing some sort of specialized streaming in
> IMAP, it instead introduces a referral mechanism, where a
> client can ask the server for a referral to a different
> protocol to stream the data. Whether this is a good idea or
> not can be debated, but this particular item is not an example
> of bloating IMAP with wild new features.

As the charter is written, it could be, even if it is your 
intent to avoid that particular path.

> 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.

Pete, my difficulty here is that there has been a lot of 
discussion the community in the last few months about basic IETF 
problems.  Two of the issues that have come up many times 
involve the IESG second-guessing the outputs of WGs and our 
having significant architectural/design issues raised only after 
the WG thinks it is finished.  I think there is general 
agreement that it is very bad situation if a WG goes off and 
produces a piece of work that falls within its charter, only to 
be confronted with arguments during Last Call that the result is 
just too complex and that the WG should be sent back to the 
drawing board.

The charter draft, as written, pretty clearly would permit the 
WG to consider and adopt some strategies that I won't find 
architecturally acceptable and that, I gather, you wouldn't 
either.  If no one intends to go in those directions, let's 
rewrite the charter to make that clear.  If the WG needs to look 
in those directions without expecting to go there, then let's 
put that in the charter, with provision for a plenary discussion 
or an IETF Last Call _before_ the in-depth protocol work has 
been done, so we don't end up with late-breaking "surprise" 
effects.

Finally, if the intent is really to prune, then I'd expect 
pruning to appear prominently in the description.  Instead, both 
the title and the text seem to point mostly to enhancements. 
And, for whatever it is worth, I seem to recall discussions when 
the IMAPEXT WG was chartered that there would be no work on 
major enhancements until/unless there was a "strip it down" 
effort first.  If the plan here were to emit a lighter-weight, 
fewer-options, version of IMAP (one, not a family of profiles) 
and then to start work on streaming and notification, I would be 
much happier than if --by intent or appearance-- the idea is to 
have some profiling emerge from an effort to move IMAP into 
previously untrod ground.

      john

---

From: Pete Resnick <[email-masked]>
Date: Wed, 29 Jan 2003 14:40:31 -0600

John and I are in a great deal more agreement that I first suspected.

On 1/29/03 at 3:06 PM -0500, John C Klensin wrote:

>But, Pete, for reasons you presumably understand, "profiles" (note 
>plural) gives me as much anxiety as "lets add lots more excrement to 
>this protocol".

Yes, if the result of this WG is multiple different profiles of IMAP, 
I too would consider that a bad thing.

>>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.
>
>there are other solutions to it, but the charter doesn't appear to 
>prevent the WG from inventing some wildly new, and complex, way to 
>handle the issue.    If it has already been decided that the WG 
>won't go down that path, then the charter should say so. If it has 
>been agreed that the WG isn't going to do that unless it turns out 
>to be absolutely necessary, then the decision point about 
>"absolutely necessary", and another opportunity for community review 
>if it is determined to be necessary, should be reflected in the 
>milestones.

I think I agree. I don't know that the solution I referred to is a 
done-deal, so I think spelling out the constraints in the charter is 
important.

In that vein, I want to take back something I said earlier:

>>*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.

I now see that the charter *as posted* might very well leave that impression.

>The charter draft, as written, pretty clearly would permit the WG to 
>consider and adopt some strategies that I won't find architecturally 
>acceptable and that, I gather, you wouldn't either.

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.

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. Though RFC 2418 says that charter review is 
only between the prospective chairs and the IESG, it also says that a 
charter is a contract between the working group and the IETF. As a 
member of this proposed WG, I'd like to know what I'm being asked to 
be involved in. I think it was irresponsible to post this charter 
without buy-in of the folks who are supposed to be working on this.

Second, I think John's concerns are right on the money, and that's 
why I pushed as hard as I did to include the profiling language in 
the work items. If we can solve the problems without extending, 
that's what we should do. If we need extensions to solve a particular 
problem, that better end up being part of a required profile.

>If no one intends to go in those directions, let's rewrite the 
>charter to make that clear.  If the WG needs to look in those 
>directions without expecting to go there, then let's put that in the 
>charter, with provision for a plenary discussion or an IETF Last 
>Call _before_ the in-depth protocol work has been done, so we don't 
>end up with late-breaking "surprise" effects.

Yup. And I think I will join in voicing objection to the charter as written.

>Finally, if the intent is really to prune, then I'd expect pruning 
>to appear prominently in the description.  Instead, both the title 
>and the text seem to point mostly to enhancements.

I want to be careful here: The *intent* of the proposed WG is to fix 
some problems with using the current protocols in particular 
operating environments. To accomplish this, it is my sincere belief 
that pruning current protocols (and more specifically, IMAP) is part 
of the solution. That doesn't mean that "pruning" needs to be in the 
title, though it certainly should appear in the work items. For that 
matter, it doesn't mean that IMAP should really appear at all in the 
charter, as far as I am concerned. The charter that I was part of 
creating didn't mention IMAP in the work items, in my mind because 
the WG should not be required to use IMAP if POP or some other 
existing protocol would do.

pr

---

From: [email-masked]
Date: Wed, 29 Jan 2003 13:06:39 -0800 (PST)

> 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.

> 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.

				Ned
Enhancements to Internet email to support diverse service environments
(lemonade)

Proposed Charter
================

Lemonade is tasked to provide a set of enhancements and profiles of Internet
email submission, transport, and retrieval protocols to facilitate operation in
environments which use Internet-based technologies but which have link
characteristics, device characteristics, or service environments that are
significantly different from those common on the Internet.  A primary goal of
this work is to ensure that those profiles and enhancements continue to
interoperate with the existing Internet email protocols in use on the Internet,
so that these environments and more traditional Internet users have access to a
seamless service.

Lemonade's work is at the crossroads of a body of work related to Internet 
messaging, in particular work done by the VPIM, FAX, IMAPEXT and other IETF 
working groups.  Given the potentially broad scope of activities this group
could engage in, the group will focus specifically on the following work items:

     0.  An informational RFC will be produced on LEMONADE requirements.

     1.  Enhance the existing IMAP4 message retrieval protocol to satisfy the
         requirements for streaming playback of multimedia content. 
         
     2.  Enhance the exsiting IMAP4 message retrieval protocol to facilitate
         its use with devices that have limited capabilities such as mobile
         endpoints. The existing standards-track CONNEG framework will be used
         if content negotiation capabilities are needed.

     3.  Create a message notification protocol for the specific purpose of
         servers reporting message status information to other servers.

     4.  Create a specification describing the use of Internet message
         services in environments where message delivery may take place using
         either Internet protocols or through an MMS server using
         WAP to communicate with the receiving user agent.

Any protocols defined by this working group will include appopriate security
mechanisms, including authentication, privacy, and access control.
Mandatory-to-implement security mechanisms will be specified as needed in order
to guarantee secure protocol interoperability.

The transport area will be consulted to deal with any transport-related
issues that arise, especially in regards to items 1-4 above.
             
The working group is aware of several related activities in other groups:

  - 3GPP TSG T WG2 SWG3 Messaging  <http://www.3gpp.org/TB/T/T2/T2.htm>
  - W3C Mulitmodal interaction Activity <http://www.w3.org/2002/mmi/>
  - Open Mobile Alliance <http://www.openmobilealliance.org/>
  - 3GPP2 TSG-P <http://3gpp2.org/Public_html/P/index.cfm>
  - 3GPP2 TSG-N <http://3gpp2.org/Public_html/N/index.cfm>

The goal is to coordinate efforts with at least these groups as required.

While there is obvious synergy, given the end-of-life of the VPIM and FAX work
groups and the similar membership, the working group does not expect to
coordinate with these other groups.

Milestones  (document completion)
==========

Feb 2003 - LEMONADE Requirements

May 2003 - Server to server notification protocol

Jul 2003 - IMAP4 extensions for VM playback

Sep 2003 - IMAP4 extensions for mobile devices

Jan 2004 - Translation to and from other messaging systems

Drafts to be used as input for working group
deliverables (grouped per milestone)
====================================

   LEMONADE requirements

     - draft-vaudreuil-um-issues-00.txt
     - draft-burger-um-reqts-00.txt
     - draft-wong-umcli-00.txt

   Server to server notification protocol

     - draft-shapira-snap-04.txt

   IMAP4 extensions for VM playback

     - draft-burger-imap-chanuse-00.txt
     - draft-nerenberg-imap-channel-01.txt

   IMAP4 extensions for mobile devices

     - draft-neystadt-imap-status-counters-00.txt
     - draft-shveidel-mediasize-00.txt

   Translation to and from other messaging systems

     - draft-vaudreuil-futuredelivery-00.txt

---

From: John C Klensin <[email-masked]>
Date: Wed, 29 Jan 2003 17:01:19 -0500

--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.
>

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

---

From: Randall Gellens <[email-masked]>
Date: Thu, 30 Jan 2003 13:56:53 -0800

At 5:01 PM -0500 1/29/03, John C Klensin wrote:

>   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.

This raises an interesting point that may be in danger of being 
obscured.  I think there is general agreement that IMAP is too 
complex.  However, concepts such as "IMAP lite" (or even "IMAP 
light"), simplification, pruning, etc. can be understood in very 
different ways.  It could mean simplifying interoperability by 
reducing options and eliminating permitted behavioral differences 
(especially among servers).  It could also mean taking out commands 
and responses.

The former can be accomplished in an interoperable way; a new IMAP 
revision or capability could be defined which includes a number of 
previous options, and specifies varies behavioral aspects (along the 
lines of RFC 1123).  Clients written to previous versions of IMAP 
would be able to interoperate with a new server just fine.

The latter, while making the protocol simpler and easier to 
understand and implement, risks being non-interoperable with previous 
versions.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
A server is only as secure as its dumbest administrator
                                         --Steve Dorner

---

From: Andrew Rutherford <[email-masked]>
Date: Fri, 31 Jan 2003 09:29:13 +1030

At 6:13 PM +0700 29/1/03, Robert Elz wrote:

>possibly fit together at all?

Voice Mail. A number of ISDN access devices without significant local
storage are capable of converting an incoming call to an SMTP stream
on the fly and spooling it to a mail server. Pretty much everyone who
is implementing this is doing it the same way, so there's no need for
the IETF to step in.

Retrieval is then easy for someone with an IMAP client on their primary
system if it's capable of playing audio, but it's more complicated if
the user wishes to retrieve the message from a phone. Currently there
are a number of different approaches to this problem - the ones I have
come across include:

1) An application between the IMAP server and the voice gateway that
retrieves the whole message, then delivers it via RTSP at the correct
rate.

2) Some other interface directly to the mail store that bypasses the 
IMAP server.

3) The voice gateway directly accessing the IMAP server and plays with
TCP window sizes and delaying acknowledgements to limit the amount of
the voice mail  stored in memory in the voice gateway at any point in
time.

In cases 1 & 2, almost always some form of proprietary signalling
protocol then runs between the access device and intermediate
application (1) or the message store (2).

My view is that whenever there are different groups trying to solve the
same problem and coming up with different, non-interoperable solutions
based on IETF-defined standards then it really is in the IETF's court
to at least consider some form of standard or informational RFC.
Lemonade seems to fit the bill.

>Is this yet another attempt to pervert

---

From: [email-masked]
Date: Thu, 30 Jan 2003 22:21:03 -0500

> is implementing this is doing it the same way, so there's no need for

Life sucks if the mail server 421's you when you don't have local storage.....

---

From: Randall Gellens <[email-masked]>
Date: Thu, 30 Jan 2003 20:39:27 -0800

At 8:07 PM -0500 1/30/03, John C Klensin wrote:

>  This really isn't worth much discussion unless someone is really 
> going to launch such an effort, but I don't see the distinction as 
> clearly as you do.

One concern I had was that there would appear to be agreement that 
lemonade would "simplify IMAP", but in reality people expected 
different things, and would then object when the WG produced 
something different.  "Simplifying" can mean different things.

>   We already have a situation in which some clients won't 
> interoperate well with some servers because the clients think they 
> need certain capabilities that those servers don't support.  And we 
> have other server authors that have refused to implement certain 
> features because they (the authors) are convinced those features 
> are brain-damaged.

True.

>  I'd like to see a WG give careful consideration to the question of 
> the damage that would be done by pulling commands and replacing 
> them with better/ cleaner designs as well as the type of revision I 
> think you anticipate with the first case.

IMAP does a lot of things.  It provides access to messages, 
information about those messages, various mailbox management things, 
access to information about mailboxes, creation of messages, and so 
on.  There's been suggestions over the years that this is really too 
much for one protocol, that, for example, mailbox management should 
be a different protocol.  There was some interest a while back in 
using ACAP to provide information about mailboxes and messages, 
leaving IMAP to just offer access to the messages.

On the other hand, one of the complaints by people implementing 
Internet mail clients on handsets and palm devices is that there are 
too many protocols, each with its own syntax.  SMTP, IMAP, MIME and 
so on all require different parsers.  Adding still more protocols 
would make this aspect worse.

>  But, in the last analysis, IMAP4bis is still at Proposed.  Like 
> you, I'd prefer something easier to implement and deploy that is 
> fully compatible with IMAP4bis.  But, if that isn't possible, then 
> I think it would be rational to consider other alternatives, with 
> the understanding that some implementations would try to be 
> conforming to both the older and newer versions and that it would 
> be wise to design things so as to make that possible.

I think people have tended to be scared of this approach.

-------------- Randomly-selected tag: ---------------
Support the League of Winged Voters              --Firesign Theatre

---

From: Andrew Rutherford <[email-masked]>
Date: Fri, 31 Jan 2003 15:05:17 +1030

>Life sucks if the mail server 421's you when you don't have local storage.....

Agreed. :-) Hopefully the gateway in question has:

(1) Got the SMTP conversation up to DATA / 354 before giving off the
"beep" that everyone expects before leaving a message - preferably even
before playing the initial greeting, so 421's from load, etc, can be
caught as early as possible.

(2) Some form of "System error" message it can then play at the person
trying to leave the message.

---

From: Robert Elz <[email-masked]>
Date: Fri, 31 Jan 2003 18:56:52 +0700

Date:        Wed, 29 Jan 2003 12:45:12 -0600
    From:        Pete Resnick <[email-masked]>
    Message-ID:  <p0600010cba5dc6d587ee@[216.43.25.67]>

First, I have now seen that the draft charter I was commenting on was
not the correct one, but for the two things I was most concerned about,
there doesn't seem to be much difference of substance...

  | No, that's not what this means. Actually, it's probably just the 
  | opposite of what you fear.

OK.   That's much more reasonable.   Now, what is needed is for the
charter to actually say that, instead of implying that (one possible)
result would be to use IMAP as a streaming video source...

Perhaps rather that the rather specific (yet imprecise) "satisfy the
requirements for streaming playback of multimedia content" what it
should be saying is something more like "allow referrals to more
appropriate protocols for retrieval of content" (or something).

  | The solution is not known. The problem is that there is currently no 
  | standard mechanism for mail servers to announce the existence of new 
  | mail. Current protocols rely on polling or a constant connection to 
  | the mail server. The work item is to come up with a protocol that 
  | does notifications. Does the above not describe that work item 
  | appropriately?

It presumes that such a protocol is the answer to something, and can
necessarily be delivered.

This looks to me to be not unrelated (in some ways) to what the msgtrack
people were working on.

If all you really want is to formalise a (rational) method to implement
biff, then that's fine, but "message status information" might be much
more than that.   As written it suggests more like a way for servers to
let other servers know when messages have been delivered, read, ... (etc).

If "announce the existence of new mail" is really the objective here,
then how about something more like

	Provide a mechanism that allows mail arrival to be detected
	without requiring polling.

kre

---

From: John C Klensin <[email-masked]>
Date: Thu, 30 Jan 2003 20:07:24 -0500

--On Thursday, 30 January, 2003 13:56 -0800 Randall Gellens 
<[email-masked]> wrote:

> This raises an interesting point that may be in danger of
> being obscured.  I think there is general agreement that IMAP
> is too complex.  However, concepts such as "IMAP lite" (or
> even "IMAP light"), simplification, pruning, etc. can be
> understood in very different ways.  It could mean simplifying
> interoperability by reducing options and eliminating permitted
> behavioral differences (especially among servers).  It could
> also mean taking out commands and responses.
>
> The former can be accomplished in an interoperable way; a new
> IMAP revision or capability could be defined which includes a
> number of previous options, and specifies varies behavioral
> aspects (along the lines of RFC 1123).  Clients written to
> previous versions of IMAP would be able to interoperate with a
> new server just fine.
>
> understand and implement, risks being non-interoperable with
> previous versions.

This really isn't worth much discussion unless someone is really 
going to launch such an effort, but I don't see the distinction 
as clearly as you do.  We already have a situation in which some 
clients won't interoperate well with some servers because the 
clients think they need certain capabilities that those servers 
don't support.  And we have other server authors that have 
refused to implement certain features because they (the authors) 
are convinced those features are brain-damaged.  I'd like to see 
a WG give careful consideration to the question of the damage 
that would be done by pulling commands and replacing them with 
better/ cleaner designs as well as the type of revision I think 
you anticipate with the first case.

But, in the last analysis, IMAP4bis is still at Proposed.  Like 
you, I'd prefer something easier to implement and deploy that is 
fully compatible with IMAP4bis.  But, if that isn't possible, 
then I think it would be rational to consider other 
alternatives, with the understanding that some implementations 
would try to be conforming to both the older and newer versions 
and that it would be wise to design things so as to make that 
possible.

     john

---

From: Randall Gellens <[email-masked]>
Date: Fri, 31 Jan 2003 12:18:26 -0800

>  let other servers know when messages have been delivered, read, ... (etc).

This is exactly what one proposal (SNAP) does: it allows one server 
to communicate status change events to another.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Quick!!  Act as if nothing has happened!