Subject: [lemonade] pull, please, not push.

From: Arnt Gulbrandsen <[email-masked]>
Date: Fri, 13 Feb 2004 14:30:51 +0100

Someone mentioned the other day that with push, SMTP/Submit extensions 
have to be mirrored in IMAP. I just realized that that, for me, settles 
it.

With Pull, it seems likely that no IMAP extensions will be optional in 
the SMTP/Submit server. The puller will require some extensions and 
never use any others. Does that seem true to you? Looking at the IMAP 
extensions to date, it seems true to me.

With Push, it seems likely to me that SMTP/Submit extensions will be 
mirrored into IMAP/Push. If that's correct, a good client has to handle 
the cases where an extension is present in the server(s), is present in 
the Submit server but not in the Push server, or is not present at all.

Down that road lies client trouble and interoperability testing hell.

Arnt (I hate combinatorial explosions of test cases)

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

---

From: Ted Hardie <[email-masked]>
Date: Fri, 13 Feb 2004 08:07:17 -0800

>
>With Pull, it seems likely that no IMAP extensions will be optional 
>in the SMTP/Submit server. The puller will require some extensions 
>and never use any others. Does that seem true to you? Looking at the 
>IMAP extensions to date, it seems true to me.

Frankly, it doesn't seem true to me, since there could be IMAP 
extensions fundamental
to one set of clients using an IMAP server and out of the area of 
interest to another
set; that certainly can be the case today.

But this raises a more fundamental point, going back to the 
"simplify, simplify,
simplify" chant I started a few days ago:  any proposal is going to need to
define how to pass through extensions of the other service without needing
to process them or to limit very severely what extensions may be used.
As Arnt points out, without that restriction you're going to end up in client
hello. For Push, Randy's proposal provides a way using Annotate to accomplish
this.  For PULL, it seems likely to me that the strict limitation would be the
better approach, so that an IMAP client built into the SUBMIT server
would not have to have a negotiation burden at all.

And since I haven't said it lately,
			just my opinion,
					Ted Hardie

---

From: Mark Crispin <[email-masked]>
Date: Fri, 13 Feb 2004 09:38:10 -0800 (PST)

On Fri, 13 Feb 2004, Ted Hardie wrote:
> For Push, Randy's proposal provides a way using Annotate to accomplish
> this.

Note that ANNOTATE is not widely deployed among IMAP servers, although in 
fairness ANNOTATE hasn't made it to RFC status yet.

ANNOTATE is a large and complex extension.  As a pre-requisite to Push, 
that means that Push is also a large and complex extension to IMAP.

> For PULL, it seems likely to me that the strict limitation would be the

This is already in Pull.  This is the purpose of the URLFETCH command.

Pull has a (modest) advantage in that the various measures of Pull are not 
pre-requisities, but instead can be layered as desired.  I say "modest" 
because most sites will probably want to deploy all of the Pull measures; 
and consequently I have not trumpted it.

For example, no IMAP extensions are strictly needed to do Pull.  URLAUTH 
is a convenience, to address what otherwise be unacceptable security 
issues in some environments.  However, URLAUTH may not be necessary in a 
Kerberos environment within a protected zone (what is highly-inaccurately 
called a "DMZ").

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

---

From: Randall Gellens <[email-masked]>
Date: Fri, 13 Feb 2004 11:13:43 -0800

With Push, the client may need arbitrary Submit extensions, and hence 
a pass-through mechanism is needed.  This is because Submit 
extensions go to the fundamental use of Submit, and hence cannot be 
arbitrarily limited when Submit is added to IMAP.  That is, by adding 
message submission to IMAP we are adding the entire functionality of 
message submission to IMAP.

With Pull, the client is submitting a message and hence itself has no 
need of IMAP extensions.  The mini-IMAP client within the Submit 
server is not a full IMAP client, and thus will have no use for any 
IMAP extensions not directly related to its task of fetching a 
limited and defined item.  With Pull, we are not adding all of IMAP 
to message submission, we are only adding a very small and 
well-defined use of IMAP to the submission server.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
And still I persist in wondering if folly must always
be man's nemesis.                    --Edgar Pangborn

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Mon, 16 Feb 2004 16:29:51 +0100

> message submission to IMAP.

Yes, agreed.

I'd like to note that the (very clever) passthrough mechanism in the 
push draft seems a little limited. More of a "BSMTP extension 
passthrough" than ESMTP, so to speak. Would it be capable of passing 
e.g. draft-ietf-fax-esmtp-conneg through? The conneg-09 draft looks 
okay, -08 doesn't. So I still think IMAP extensions are needed for some 
SMTP/Submit extensions.

> well-defined use of IMAP to the submission server.

Quite. Much more manageable.

Arnt