Subject: [lemonade] Mobile messaging clients barriers

From: Mendelovich Meir <[email-masked]>
Date: Fri, 13 Jun 2003 12:55:02 +0300

Hi,
 I'm very happy to see that a consensus is forming about the need to add
message submission to IMAP4.
 But, this is only one of several barriers that prevent us from building
good mobile messaging clients. I want to raise two major problems. All the
details are in section 7.1 of the requirements document that was presented
by Wong and me in San-Francisco
(http://www.ietf.org/internet-drafts/draft-wong-umcli-02.txt
<http://www.ietf.org/internet-drafts/draft-wong-umcli-02.txt> ).

1. As Alan Stebbens mentioned, server-side processing of media is crucial.
We can't download 3 mega pixel image with 30bit color depth to device that
has 100X100 pixels screen and 8bit color depth. We don't expect mail servers
to implement image processing but it is needed to allow IMAP4 servers or
mobile messaging gateways to use external transcoding engines to provide
their mobile client better experience. 
In the MMS arena it is very hot issue. OMA prepares now a standard interface
for transcoding servers.

2. It is very hard to maintain long sessions in mobile networks. The current
statefull nature of IMAP4 prevent many clients from providing good
experience. Most of the mobile handsets that has IMAP4 client open and close
new session for each command. This kind of behaviour cause enormous load on
the server and spend lots of bandwidth. We MUST solve this problem if we
want to see real mobile e-mail solution in GPRS and CDMA1X networks.

From our experience in mobile messaging clients these two problems must be
solve to fulfill the LEMONADE goals.

	Meir :->

__________________________________

Meir Mendelovich
Product Engineer
Comverse
              
Tel:     +972-3-765 5834
Cell:    +972-5854-3834
Fax:    +972-3-765 5834
E-mail: [email-masked]

---

From: Cyrus Daboo <[email-masked]>
Date: Sat, 14 Jun 2003 10:20:16 -0400

Hi Mendelovich,

--On Friday, June 13, 2003 12:55 PM +0300 Mendelovich Meir 
<[email-masked]> wrote:

| 2. It is very hard to maintain long sessions in mobile networks. The
| current statefull nature of IMAP4 prevent many clients from providing
| good experience. Most of the mobile handsets that has IMAP4 client open
| and close new session for each command. This kind of behaviour cause
| enormous load on the server and spend lots of bandwidth. We MUST solve
| this problem if we want to see real mobile e-mail solution in GPRS and
| CDMA1X networks.

Sadly this is also an issue for regular desktop clients sitting behind 
firewalls and cable/DSL modems. Typically those types of device have idle 
connection timeouts set to a value much less than the IMAP minimum of 30 
minutes and they end up unilaterally disconnecting the client/server.

This issue is also significant for some webmail implementations where, due 
to the nature of the http server, its difficult to maintain (imap) state 
across http requests.

A good solution to this is to have a proxy which is in effect an imap 
client on one end (that maintains the server connection and caches mailbox 
data), and a server (of some sort) on the other. One could then access this 
proxy by regular IMAP, mIMAP, HTTP, or any other mechanism that would make 
sense. The proxy could then handle composition/submission etc as already 
discussed. I think there is at least one simple connection caching proxy 
that's being used with webmail solutions right now.

-- 
Cyrus Daboo
_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade

---

From: Mark Crispin <[email-masked]>
Date: Sat, 14 Jun 2003 09:00:47 -0700 (PDT)

> that's being used with webmail solutions right now.

This sounds like a concensus is forming around developing this proxy --
which will provide multiple necessary services for mobile clients
including submit -- and NOT to hammer all this into IMAP.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.
_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade

---

From: Ken Murchison <[email-masked]>
Date: Sat, 14 Jun 2003 12:50:36 -0400

Cyrus Daboo wrote:
> client on one end (that maintains the server connection and caches 
> mailbox data), and a server (of some sort) on the other. One could then 
> access this proxy by regular IMAP, mIMAP, HTTP, or any other mechanism 
> that would make sense. The proxy could then handle 
> composition/submission etc as already discussed. I think there is at 
> least one simple connection caching proxy that's being used with webmail 
> solutions right now.

There are at least two that I know of, one of which is right in your own 
backyard at Pitt.

http://www.imapproxy.org/
http://www.horde.org/imapproxy/

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

---

From: Pete Resnick <[email-masked]>
Date: Sat, 14 Jun 2003 12:24:50 -0500

>This sounds like a concensus is forming around developing this proxy --

1) It is for the chairs to call concensus.

2) I don't think "Mark and Cyrus think it's a good idea, Doug and 
Pete have expressed reservations about it, and a couple of other 
people say they are considering it" makes for anything you can call 
consensus.

I think the complexity introduced by a proxy I think is higher than 
the other choices, the idea of developing an entirely new protocol 
for mobile clients to access IMAP and SMTP through a proxy seems way 
outside of the scope of our charter, and the suggestion that 
something like mIMAP or HTTP would be used smacks of WAP. I *thought* 
our purpose here was to make things easier for mobile clients using 
*current* protocols, either by simplifying implementation 
requirements for current protocols (what we've called "profiling" in 
the charter for lack of a better word) or, when absolutely necessary, 
creating new commands for current protocols. I'd like to hear where 
our chairs are on this.

pr
-- 
Pete Resnick <mailto:[email-masked]>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade

---

From: Mark Crispin <[email-masked]>
Date: Sat, 14 Jun 2003 12:39:13 -0700 (PDT)

On Sat, 14 Jun 2003, Pete Resnick wrote:
> I have never heard anyone claim that anything other than
> submit-in-IMAP is out of charter. I certainly don't think that
> Chris's proposal is out of charter.

Strange that it's called "Chris' proposal" when it is really an
elaboration of something that I originally brought up (and which you
shouted down, although later you apologized).

> I do question whether an entirely
> new proxy protocol is within charter and would like to hear the
> chairs' opinions on that, but I was also asking whether the chairs
> had any opinion on the state of consensus.

The state of compose and submit sucks.  I think that we can all stipulate
to that.  Whatever happens, something new has to be done to fix the
suckage.

The proxy proposal is a means to that end, but it isn't an end in itself.
Thus, I consider it in charter, although I'm willing to agree that it's
testing the boundaries and can only proceed with restraint.

-- Mark --

---

From: Mark Crispin <[email-masked]>
Date: Sat, 14 Jun 2003 11:16:15 -0700 (PDT)

> people say they are considering it" makes for anything you can call

I am disappointed that you would say this, after having let pass a claim
of concensus that you probably agreed with.

> I *thought*
> *current* protocols

Carrying that argument to its logical conclusion, it is out of order to
propose submission in IMAP because the current protocol to submit is SMTP;
therefore any effort to make submit easier for mobile clients must be done
in SMTP.

> I'd like to hear where

A ruling from the chairs to the effect that submit-in-IMAP is the only
in-charter solution would have the effect of rendering meaningless any
pretense of fairness in this WG.

-- Mark --

---

From: Lawrence Greenfield <[email-masked]>
Date: Sat, 14 Jun 2003 14:18:23 -0400

--On Saturday, June 14, 2003 12:24 PM -0500 Pete Resnick 
<[email-masked]> wrote:

> I think the complexity introduced by a proxy I think is higher than the
> other choices, the idea of developing an entirely new protocol for mobile
> clients to access IMAP and SMTP through a proxy seems way outside of the
> scope of our charter, and the suggestion that something like mIMAP or
> HTTP would be used smacks of WAP. I *thought* our purpose here was to
> make things easier for mobile clients using *current* protocols, either
> by simplifying implementation requirements for current protocols (what
> we've called "profiling" in the charter for lack of a better word) or,
> when absolutely necessary, creating new commands for current protocols.
> I'd like to hear where our chairs are on this.

I agree with this. Introducing yet another access protocol and the security 
complications of proxy servers strikes me as exactly the wrong thing to do.

If the problem is long running TCP sessions, let's try to understand that 
(that's one complaint I've seen with IMAP). If the problem is having to 
initiate new TCP sessions (a complaint with submit only through SMTP) let's 
understand that.

Larry

---

From: Pete Resnick <[email-masked]>
Date: Sat, 14 Jun 2003 15:09:31 -0500

On 6/14/03 at 12:39 PM -0700, Mark Crispin wrote:

>>I certainly don't think that Chris's proposal is out of charter.
>
>elaboration of something that I originally brought up

Oy, vey. I called it "Chris's proposal" because I first wrote 
"submit-in-SMTP", didn't like it, erased it and wrote 
"submit-in-MTA", didn't like it, erased it and then wrote "Chris's 
proposal" because he's the one who posted the straw man to the list. 
Is it really necessary to personalize each and every comment?

>(and which you shouted down, although later you apologized).

Which I shouted down because it came to the mic after the chairs 
closed down discussion in the face-to-face meeting and I thought it 
was unfair to bring up a new topic with no opportunity for 
discussion, not because I thought it was out of charter. And yes, I 
did apologize for shouting.

>The state of compose and submit sucks.  I think that we can all 
>stipulate to that.  Whatever happens, something new has to be done 
>to fix the suckage.

Agreed.

>The proxy proposal is a means to that end, but it isn't an end in 
>itself. Thus, I consider it in charter, although I'm willing to 
>agree that it's testing the boundaries and can only proceed with 
>restraint.

Understood.

pr

---

From: Pete Resnick <[email-masked]>
Date: Sat, 14 Jun 2003 13:27:56 -0500

On 6/14/03 at 11:16 AM -0700, Mark Crispin wrote:

>I am disappointed that you would say this, after having let pass a 
>claim of concensus that you probably agreed with.

I don't understand to what you are referring.

>>I *thought* our purpose here was to make things easier for mobile 
>>clients using *current* protocols
>
>Carrying that argument to its logical conclusion, it is out of order 
>to propose submission in IMAP because the current protocol to submit 
>is SMTP;

Uh, not if you include the rest of the sentence that you quoted:

"either by simplifying implementation requirements for current 
protocols (what we've called "profiling" in the charter for lack of a 
better word) or, when absolutely necessary, creating new commands for 
current protocols."

Don't take this out of context: What I was arguing against creating 
an entirely new proxy protocol rather than using either IMAP or SMTP 
to do the job.

>A ruling from the chairs to the effect that submit-in-IMAP is the 
>only in-charter solution would have the effect of rendering 
>meaningless any pretense of fairness in this WG.

Chris's proposal is out of charter. I do question whether an entirely 

pr

---

From: Doug Royer <[email-masked]>
Date: Sat, 14 Jun 2003 16:47:37 -0600

Pete Resnick wrote:

> other choices, the idea of developing an entirely new protocol for 
> mobile clients to access IMAP and SMTP through a proxy seems way outside 
> of the scope of our charter, and the suggestion that something like 
> mIMAP or HTTP would be used smacks of WAP. I *thought* our purpose here 
> was to make things easier for mobile clients using *current* protocols, 
> either by simplifying implementation requirements for current protocols 
> (what we've called "profiling" in the charter for lack of a better word) 
> or, when absolutely necessary, creating new commands for current 
> protocols. I'd like to hear where our chairs are on this.

I agree. However if the proxy program could be written such that
IMAP commands were sent straight through to an IMAP server, and
IMAP replies came straight back through the proxy. (+/- any
handshakes). And any new submit commands were routed to some new
submit server then it would not be a 'new' protocol. Just extensions that
when sent through a submit-imap proxy did what you wanted.
In effect it is extending the IMAP protocol, yet existing
IMAP servers could be used for the non-submit part of the work.

Alan's idea (sorry if some one else said it first), of using
the OUTBOX also seems much easier that a proxy. A process
could just scan the OUTBOX (entries created by the IMAP
APPEND command), and process them. It could set any bounces
directly into the users INBOX. The only thing to do is to
define a capability so that any IMAP client knows and asks for it
to happen. Then define how 'include/forward this blob' is going
to work.

The external mime body part already can be used by existing
tools to mean 'do NOT include', so maybe a 'include mime
body part' needs to be invented.

-- 

  Doug Royer                     |   http://INET-Consulting.com
  -------------------------------|-----------------------------
  [email-masked]                 | Office: (208)612-INET
  http://Royer.com/People/Doug   |    Fax: (866)594-8574
                                 |   Cell: (208)520-4044

                 We Do Standards - You Need Standards

---

From: Mark Crispin <[email-masked]>
Date: Sat, 14 Jun 2003 17:08:56 -0700 (PDT)

On Sat, 14 Jun 2003, Doug Royer wrote:
> However if the proxy program could be written such that
> handshakes).

Yes, it should certainly be a requirement that a proxy program offer a
means to send/receive raw IMAP from the real IMAP server.

> IMAP servers could be used for the non-submit part of the work.

That is a way of looking at it; and if that makes it a more acceptable
solution to some then that's fine with me.

It *would* be nice if the proxy could be extensible enough so that future
hooks into NNTP, etc. could be made.  That implies that the base level
proxy operations be powerful enough, e.g. at least have a "get overview"
and "get message" operation.  But if this ruffles some feathers then I can
punt on that part.

-- Mark --

---

From: [email-masked]
Date: Sun, 15 Jun 2003 08:33:00 -0700 (PDT)

> > I'd like to hear where our chairs are on this.

The LEMONADE charter is very clear: Most of the WG's tasks are supposed to be
done by enhancement or profiling of either IMAP4 or SMTP submit. The one
exception is notifications. These restrictions were very intentionally
added to the charter because of IESG concerns regarding WG scope.

Speaking as the AD in charge, I believe a charter revision would be best in
order to proceed along the path of developing a proxy. This doesn't have
to be a big deal, and if the WG does decide to develop a proxy it will
likely avoid a lot of trouble later by having it in the charter.

Of course this presupposes the WG actually reaches consensus to solve
this set of problems with a proxy.

> complications of proxy servers strikes me as exactly the wrong thing to do.

I also am very concerned about the security complications of a proxy-based
approach.

> initiate new TCP sessions (a complaint with submit only through SMTP) let's

I also would like to understand the long running session / session initiation
issue(s). I will also point out that if reliable connections to servers really
are an issue there is an entire IETF WG devoted to solving this particular
problem:

  http://www.ietf.org/html.charters/rserpool-charter.html

If the WG decides that work in this space is in order the RSERPOOL approach
needs to at least be considered.

				Ned