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

From: Pete Resnick <[email-masked]>
Date: Wed, 29 Jan 2003 15:50:05 -0600

On 1/29/03 at 1:06 PM -0800, [email-masked] wrote:

>I regard this as being up to the chair of the group. The charter 
>[...] was iterated on by both the chairs and the IESG.

Ned is right. This is up to the chairs. I think it is a 
responsibility of the chairs. So, on that note:

We spent a good deal of time on this list getting the "profile" 
language into the original version of the charter. Why did the chairs 
agree to having it removed without consulting with the list, and what 
reason was there for removing that language? Is "enhance" supposed to 
include "extend and/or profile"? Certainly the September 2003 
milestone says "extensions". Also:

- Why was IMAP called out specifically? Does the IESG really prefer 
this group to use IMAP over other choices?
- What does "other servers" mean in the context of item 3?
- Is discussion of message submission summarily out of scope now?

pr
-- 
Pete Resnick <mailto:[email-masked]>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
-
This list is maintained by Snowshore Networks - http://www.snowshore.com
All comments on this list are the comments of the message originators and
Snowshore is not to be held responsible for any actions or comments found
on this list. The archives for this list can be found at
http://flyingfox.snowshore.com/um_archive/maillist.html

---

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

I also dislike the addition of specific references to WAP.  We don't 
want to exclude HTTP based MMS from the same consideration as 
WAP-based (especially since WAP includes optional use of HTTP).

Echoing what Pete said, what did happen to message submission?  That 
seems to be a very important components (especially features such as 
forward-without-download and so on).
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Law of Probability Dispersal:  Whatever it is that hits the fan will
not be evenly distributed.
-
This list is maintained by Snowshore Networks - http://www.snowshore.com
All comments on this list are the comments of the message originators and
Snowshore is not to be held responsible for any actions or comments found
on this list. The archives for this list can be found at
http://flyingfox.snowshore.com/um_archive/maillist.html

---

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