Subject: [lemonade] Push, I say Push, son.

From: Ted Hardie <[email-masked]>
Date: Tue, 10 Feb 2004 17:53:00 -0800

(For those not addicted to cartoons as children, the above is
a reference to Foghorn Leghorn, a large cartoon rooster).

I believe PUSH is a better way forward than PULL.  I agree with the
points Greg has made.  A few more below, but before that, an
overarching concern:

PUSH or PULL:

Simplify, simplify, simplify.  Whatever choice this working group
makes (PUSH or PULL), it is critically important that we keep focus
and do not allow this work item to expand past our capabilities.
Getting nothing done is far worse than choosing a sub-optimal
solution.

In favor of PUSH:

1) I believe PUSH will be easier to implement and deploy in the environments
that need it most.  The need  we're addressing is one for clients
in limited-capacity environments.  That need is real, it is a major
problem for wireless deployments today, and there is a real risk
that delay will cause the need to be met with protocols not based
in the email world at all.  That's a serious risk to interoperablity,
and a serious mistake.  If you are worried about imapd+sendmail,
you should also be worried about sendmail+apache, which is
a major risk of placing this burden on the submit server.

2) It is relatively easy to chain this service in ways that meet common
network topologies in both wireless and enterprise environments.
Having an IMAP/submit server speak to a next hop MTA inside an
administrative boundary is relatively easy, and the next-hop
MTA can handle the majority of queueing and retransmission.

3)  IMAP's complexity has historically been made worse by
behavior variations, and it is historically the clients which
have been required to handle the majority of that variation.  It is
also true that adding complexity to any service is a deterrent to
implementation and deployment.  But in this case, the client's
view of this is that the functionality needed is core to the
IMAP service--it is "access to a mailstore".  Rather than "download
access" to a mailstore, it is "forward access", and, from a client's
point of view, these are very strongly related sets of actions and
permissions.  Shifting the actions and permissions to another
protocol which has no similar functionality is not a client-friendly
action.

4) It does not require a fundamentally new security model.  While I
think URLAUTH may eventually be very useful, I have concerns both
about how it ties authorization to location and in the deployment
of a "pawn ticket" model of authorization.  As it stands, this is
not just undeployed code;  authorization without authentication is
not in the security lexicon of many people.  Even with a great deal more
security review in the IETF, there is a serious risk that deployment would
be stalled by the unwillingness of corporations to shift away from
authentication/authorization mechanisms.

5) I believe PUSH avoids both some race conditions and some very
serious risks of head-of-line blocking issues; even in multithreaded
servers, a long delay in reply by a server accessed for PULL can consume
network buffers and raise the risk of a denial of service.

I also disagree with Chris's assertions on a number of points, but I
will reply to those in a separate message.
			regards,
					Ted Hardie

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

---

From: Chris Newman <[email-masked]>
Date: Wed, 11 Feb 2004 16:56:33 -0800

> Getting nothing done is far worse than choosing a sub-optimal

Pull is much simpler than push.  I have first-hand experience writing and
supporting mini IMAP clients, IMAP proxies, IMAP servers, SMTP clients, SMTP
proxies and SMTP servers.  Push involves putting an SMTP proxy into an IMAP
server.  Pull involves a very thin IMAP client in SMTP plus GETURL.  My
estimate is that push requires 2-3 times as much code overall than pull does
and therefore pull is simpler.

> a major risk of placing this burden on the submit server.

You're missing the distinction between a proxy and a client.  Push is a proxy
problem and it's easier to link two servers than write a good proxy, thus you
get uw-imapd+sendmail.  Pull adds a mini URL resolution client to the submit
server, so you'll get sendmail+libwww (or the equivalent).

Pull is definitely easier to implement and deploy.

> MTA can handle the majority of queueing and retransmission.

Having written an SMTP proxy, I can assure you this is not "relatively easy".
I'd call it subtle and challenging.

> protocol which has no similar functionality is not a client-friendly

IMAP already provides read/write access to a mailstore with FETCH, STORE and
APPEND.  You are adding completely new functionality to IMAP: the ability to
transfer messages to other message stores.

But what you're really getting at is that client vendors see "send mail" and
"read mail" as closely related functions and due to their hostility to multiple
TCP connections, they want them in one protocol.  But this path leads to
madness.  Outlook has raised the bar so the client vendors now see "send mail",
"read mail", "access calendar" and "schedule calendar events" as closely
related functions and due to their hostility to multiple TCP connections, they
want them in one protocol.  I'm told there are are deployed systems which use
IMAP for calendar storage and scheduling today.

While client implementer perception is one of the stronger arguments for the
push model, it is not strong enough to merit a complete destruction of the
functional separation we have today at the protocol level.

> authentication/authorization mechanisms.

You haven't been keeping up with the recent pull specs.  The latest specs make
"authrole=submit" mandatory to implement so we're back to a traditional
authentication model, but using the signed URL to provide fine-grained
authorization for the submit server.

> network buffers and raise the risk of a denial of service.

The race condition is an issue, but I don't see it as a significant issue.

MTAs already have to deal with all the buffering, blocking and
denial-of-service issues when implementing SMTP.  With pull, they can simply
re-use the logic (which they fully understand) when implementing a tiny IMAP
client.  But IMAP servers don't make connections to the network (with the
possible exception of login) so most IMAP implementers have never dealt with
the class of denial-of-service and buffering issues they will face with the
push model.  They'll have to pull all the complexity and logic that's already
in the SMTP servers down into the IMAP server to deal with these issues.

                - Chris