Re: IM2000 Won't Be Worth It

>On Sun, Mar 07, 2004 at 10:38:20PM -0000, James Craig Burley wrote:
>>     Though JdBP and Charles Cazabon hand-wave this in different ways
>>     (JdBP says "if the network is down, you didn't get your email via
>>     SMTP anyway"; CC says "if the network is down, you can't reach
>>     your POP box anyway"), the *claim* made by IM2000 proponents is
>>     that IM2000 recipients *DO NOT PAY* for the sizes of their
>>     in-boxes, but SMTP recipients *DO*.
>
>As far as I can see, this is not the problem.  The problem is the cost
>of maintaining the network connection.  In case of IM2000, it seems
>the recipient needs to maintain network connection while he is trying
>to decide which email actually to see.

The problem has different manifestations under different scenarios.
You're identifying an important one.  I identified another important
one.  The fix for each of them is essentially the same, and IM2000
makes such a fix quite straightforward AFAICT -- but at a cost of
defeating one of its major stated advantages.

Essentially, no offline reading of incoming email is permitted under
the simplified IM2000 scenario, because, under that scenario, one's
in-box consists merely of incoming-message *notifications*, without
the messages themselves.  That's the general description of the
problem.

That problem manifests itself in different ways.  For people like your
mother, and myself pre-Broadband (when I used dialup, but didn't want
to tie up my phone line for longer than strictly necessary -- despite
not paying for the call, I just had a real problem making myself leave
the connection up when I wasn't using it), that means they won't be
able to determine which emails are worth reading (in IM2000, this
means "worth pulling down from originating-message store") while
offline, and doing it online will cost a lot more than with delivery
of messages directly into their in-box (the SMTP design).

For people like myself *now*, who have nearly-constant flat-rate
Internet access but also get important email from arbitrary people all
over the globe (and, in the past when I worked on g77, that included
appreciative emails from China and Cuba), the definition of "offline"
includes the *originating message store* (say, in China or Cuba) being
offline or unavailable when *I* decide to read the message.  So my
inbox potentially consists of a hodgepodge of available and
unavailable messages, with precious little information on the
unavailable ones.  Whereas with SMTP-style injection, I can read my
incoming messages while offline unless my in-box *itself* is
unavailable while offline (or messages contain just pointers to
resources that are unavailable, such as web pages).

With both scenarios, which represent fairly common ones worldwide, the
fix is simple: configure your IM2000 message notification recipient
agent to automatically pull down each incoming message and either
cache it locally (leaving it "pinned" on the originating message
store) or take responsibility for it (letting the originating message
store delete it).

That fix defeats *the* major advertised advantage of IM2000, and does
so for a large percentage of its intended user base.

But for users who have no need for this "fix" -- users who accept
whatever delays they might experience opening each in-box email for
reading as they scan the contents of their in-box -- IM2000 beats SMTP
hands-down, because there is no *reliable* way to provide this
capability without also putting the burden on the recipients to
provide storage for all their incoming messages.

I think such users would be well-served by IM2000, but not enough of
them exist to overwhelm the remaining audience for SMTP-style
delivery, such that it's worth deploying IM2000 as an SMTP replacement
overall.

>In Eastern Europe, this is a cost people would not tolerate.  For
>example, my mother automatically discards messages greater than
>30K---so your 65K message would have never made it to her mailbox.

IM2000 is better than SMTP in this sense, though, because, presumably,
it offers a cleaner way for agents acting on her behalf (her MUA, her
message recipient notification agent, whatever) to inquire as to the
size of an incoming message *before* any attempt is made to pull it
down from the originating message store.

With SMTP, inelegant and kludgy means to accomplish the same thing
also exist.  Can't recall for sure offhand, but I'm pretty sure there
are means for an SMTP server to specify a SIZE limit on an incoming
message *after* it sees the RCPT TO for it -- if not, this is an
example of something that could be added as a kludge to the SMTP
protocol.

(E.g. after "RCPT TO:<...>", a multi-line response a la the EHLO
response could provide info to the SMTP client saying things like
"2xx-SIZE 300000".  That would save the client that recognizes such a
thing the trouble of transmitting the message in the first place.  Or
the server could rely on SIZE information transmitted with DATA and
reject it at that point; with that approach, one can "solve" the case
of multiple RCPT TOs identifying recipients with different size
restrictions by either using the maximum size in the set of limits and
then bouncing the rest after receipt, or just temporarily rejecting
any RCPT TO's after the first one in order to get a "clean" interface
per-recipient.  That potentially wastes bandwidth, but vanilla IM2000
has bandwidth-wasting implications in this area as well.)

So, your mother's PC might not have had to download the 65K message
via her dialup before rejecting it, but the message probably *was*
received via SMTP by agents acting on her behalf.  (That's wasted
bandwidth, though it's wasted *upstream*, where its costs are more
easily aggregated via economies of scale.)

With IM2000, that wouldn't necessarily happen, and it wouldn't happen
using a somewhat-cleaner mechanism than it could be made to not happen
via SMTP.  (Wow, *that's* a tortured sentence!)

In other words: IM2000 is better in this particular respect, but not
better *enough* to justify a rollout as a replacement for SMTP, since
it's probably cheaper, easier, and more robust to augment SMTP to do
the required functions on just those systems whose users need it.

-- 
James Craig Burley
Software Craftsperson
<http://www.jcb-sc.com>