Subject: RE: [lemonade] Re: IMAP as a submit server

From: "Vaudreuil, Greg M (Greg)" <[email-masked]>
Date: Wed, 11 Jun 2003 11:57:15 -0500

Rick, 

I believe there will be two modalities going forward, with separate protocols and constituencies.  I don't expect much "mix and match".

1) POP (or IMAP) plus SMTP-Submit, for basic email client support.  Bandwidth is cheap, clients are smart, server capacity is limited relative to cheap PCs, and complexity is simply not worth it.

2) IMAP plus IMAP-Submit (maybe via SMTP/IMAP splitting proxy) for mobile optimized or media aware (UM) clients.  Clients resources are limited (connectivity, storage, CPU power, battery power), network resident servers are relatively cheap, and complexity that saves $$ or enables new services is worth paying for. 

POP and SMTP-Submit will continue to be evolve but are essentially "mature" services.  The mobile "lemonade" clients require substantial new functionality to simply function economically in a new market segment.  These protocols need to compete against existing "MMS" solutions that are optimized for the mobile network.

Building a completely new protocol to replace IMAP and SMTP for mobile clients is out-of-scope.  While academically interesting, the WG and IESG has rejected that route. 

Greg V.

-----Original Message-----
From: Rick Block [mailto:[email-masked]]
Sent: Tuesday, June 10, 2003 1:26 PM
To: Pete Resnick
Cc: Mark Crispin; Vaudreuil, Greg M (Greg); [email-masked]
Subject: Re: [lemonade] Re: IMAP as a submit server

Does the "IMAP as submit protocol" proposal imply that clients
using it will use two different submit protocols, IMAP for
messages containing bits of others and SMTP for messages
originated in toto by the client?

It seems to me either the answer to this question is:

yes, in which case I would think the client developers would
not be very happy (two different protocols for submitting
messages, based on the context of the composition?)

or

no, in which case it would seem the IMAP "submit" capabilities
must be a superset of SMTP (for example, it would seem
IMAP submit would have to support the client side of quota
if not lemonade's quota by media)

In addition, what shall an IMAP server do if an SMTP submit
it's been requested to do (via some new IMAP operation) fails,
or will the IMAP server be required to do the resultant SMTP
submit synchronously so any SMTP error can be conveyed back
to the original client with an IMAP response?

I understand the appeal of an IMAP submit mechanism, but it
seems this effectively requires completely merging IMAP and SMTP.
Perhaps we should be talking about an entirely new protocol that
really is a combination of IMAP and SMTP and could be implemented
by a server that effectively proxies independent (regular) IMAP
and SMTP sessions.

Rick Block
Avaya Inc.
_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade

---

From: Mark Crispin <[email-masked]>
Date: Wed, 11 Jun 2003 10:22:43 -0700 (PDT)

On Wed, 11 Jun 2003, Vaudreuil, Greg M (Greg) wrote:
> 2) IMAP plus IMAP-Submit (maybe via SMTP/IMAP splitting proxy) for
                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

> Building a completely new protocol to replace IMAP and SMTP for mobile
> clients is out-of-scope.  While academically interesting, the WG and
> IESG has rejected that route.

I do not see how the underlined text can be resolved with the latter
statement.  I also question about how the "WG" could have rejected
anything, given that the WG was just recently formed.

Perhaps you intended "completely" to be a moderating word.  If so, I think
that needs clarification.

The SMTP/IMAP splitting proxy *is* a new protocol.  It can be chartered to
be a "user" of SMTP/IMAP as opposed to a replacement of SMTP or IMAP.
Indeed, the proxy should be defined in terms of what SMTP and IMAP will be
generated (although there *is* the prospect of substitutes, most obviously
NNTP in the short-term).

If this constitutes "not a completely new protocol" and thus an acceptable
route to you, please say so.

The more I think about it, the more that I think that the proxy may be a
good way out of the problem.  We have chattiness and RTT problems with
both SMTP and IMAP.  We have timing race problems with IMAP.  We have an
issue of installed base.

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