Re: IM2000 Won't Be Worth It

>Ian Lance Taylor <[email protected]> wrote:
>> I think the main argument is eliminating bounce messages and
>> simplifying mailing lists.
>
>The no-subscription model of mailing lists is certainly interesting.
>But what does it achieve that cannot be achieved via NNTP today?

Isn't NNTP a push protocol, requiring its subscribers to, essentially,
pay for maintaining incoming messages somehow?

Also, NNTP is a store-and-forward protocol, correct?  (Been so long
since I used it....)  So its advantages, and disadvantages, associated
with it being able to deliver large chunks of disparate messages
across a network that is up for only limited periods of time (e.g. via
UUCP), are lost with IM2000.

Whereas, IM2000 offers a clean way to implement one model of message
submission to the list and its resulting distribution: one in which
the *submitter* keeps the message on his outgoing message store, and
merely *notifications* are distributed among list members.

This will teach people who submit 63K messages that nobody wants to
read to lists to not do that, and make people who receive such
messages be a bit less annoyed.

;-/

>Also, how do "subscribers" know when there is new mail to be fetched?

There are at least three fundamentally different models of list
handling I can think of that IM2000 cleanly supports:

  -  Simple exploder, in which contents and notifications get
     replicated by the exploder bot.  This is most like ordinary
     SMTP-based mailing lists.

     The exploder must bear the costs for storing such email for as
     long as anyone might want to read it.  Since many exploders are
     tied in to providing web-based archive access to such messages
     anyway, that's often just fine with the list maintainer.

  -  Notification exploder, in which notifications get replicated by
     the exploder bot, but message contents remain with the sender.
     This is closest to IM2000's vanilla "pull"-style delivery.

     The person submitting a message to the list must bear the costs
     for storing the email.  This reduces the need for the exploder to
     deploy aggressive anti-UBM measures, as long as the notifications
     faithfully record the original envelope and transmission
     information as received by the exploder from the submitter.

  -  Non-exploder, in which notifications as well as contents must
     be "pulled", i.e. polled, by recipients.  This is kinda like
     using the news:// (NNTP) protocol, or reading mailing-list
     discussions by polling their archives.

     For high-volume lists, all the list maintainer need do is keep
     track of submissions of notifications, serve up notifications as
     requested by recipients polling for them, and (therefore) keep
     track of the "known-notifications" status for each of its
     subscribers.

     Though IM2000 doesn't seem naturally architected for this
     arrangement, it kinda is, in the sense that each such list
     provides a recipient notificiation agent for each of its
     subscribers, just as anyone with an ordinary in-box has some
     recipient notification agent that their MUA queries to learn
     about new incoming messages.

     So, MUAs must be distinctly aware of such lists, because they
     cannot rely on querying just one recipient notification agent to
     learn about all incoming mail.  They'll have to be told of all
     the agents to query, all the lists to which the recipient is
     subscribed.

     The SMTP, or really push, "equivalent" of this would be for lists
     to push messages not directly to recipient mailboxes as with
     today's architecture, but into per-recipient mailboxes (a la POP3
     or IMAP) that are local to the list systems' themselves.  MUAs
     operating in this environment would also have to know to retrieve
     emails from those mailboxes, as well as the ordinary one local to
     the recipient's system.  And lists set up this way wouldn't have
     to deal with the expense of large outgoing mail submissions to
     SMTP servers; just with pull-style requests for messages already
     in out-boxes (which would really just be notifications plus links
     to a single copy of each message).

Note that, since a non-exploder list can offer an outgoing message
store for submitters to use, the system described by JdBP, in which
list messages and their notifications are not "exploded", yet the
message contents are stored locally to the list manager a la the
"simple exploder" case above, is fairly cleanly supported by IM2000.
Either the submitter of a message can directly submit to such a store
(his MUA knows about it), or a submission coming from another such
store can be handled by the manager taking responsibility for the
message and moving it to the local store.

In essence, with lists that are "cleanly" managed via IM2000, even
though the list manager doesn't have to "push" messages -- it doesn't
have to maintain message-based lists of to whom each message has or
hasn't been delivered -- it does have to maintain subscriber-based
lists of to whom each *notification* has or hasn't been delivered.

If a list manager doesn't want to manage anything other than accepting
submissions, then IM2000 makes that fairly easy, by basically always
notifying anybody who polls about every single message, or leaving it
up to each subscriber to provide some indicator of what messages they
already know about, which recipient MUAs would have to deal with, by
keeping state information on each list.  (I can't tell from JdBP's
page, offhand, how such information is managed across the boundary
between MUAs and recipient notification agents.  Note that the issue
of notifications is orthagonal to whether the manager wants to
maintain an outgoing message store along with the list itself.)

However, that's basically the same thing as having a list consist of
accepting messages and putting up a web page for each one, leaving it
up to recipients and their browsers to decide which messages have
already been read.

So it's not really IM2000-specific so much as specific to whether
messages and/or notifications are pushed and/or pulled (polled), and
to whom has responsibility for keeping track of what a given user has
already been told about and/or read.

>Currently, if I am on a mailing list I know about new messages
>essentially immediately. It's not very efficient to have every
>"subscriber" contacting the message store every 5 seconds to see if
>there is new mail!

No, but for lists that would be polled by most subscribers only once
every few days or so, it can be *very* efficient compared to on-demand
push-style delivery a la SMTP.

>> Bounce messages are bad because they are widely mishandled today, and
>> there is no realistic prospect for improvement.  Today there is no
>> good way to know whether somebody received an e-mail message, short of
>> telephoning them.  IM2000 raises the possibility of solving that
>> problem (you still won't know whether the message was read, but you
>> will know that it was received).
>
>What does it achieve that Return-Receipt-To does not already achieve,
>or that could not be achieved by a simple protocol to allow MUAs to
>inspect their SMTP smarthost's outgoing mail queue? Is it actually
>useful to know that a message has been received but not necessarily
>read?

All SMTP-style DSNs (that I know of) are heavyweight reactions to
lightweight actions, so they are simply *wrong*.  To the second part
of that first question, I say, basically, "nothing": IM2000 isn't the
only protocol that can (or would) require a transition to sender-side
tracking, since shims connecting SMTP to IM2000 would end up requiring
that for people still submitting messages via SMTP.

To your second question, I'll say "sometimes", because, for many
messages, people just want to know that the mail agent (usually, an
MUA, like mutt or a PDA or whatever) closest to the recipient has
received the message.

And there's simply little or no point, IMO, to trying to go the "extra
mile" and automatically confirm whether someone has actually *read*
the message, because that gets into issues such as whether the message
has appeared on the MUA/PDA screen vs. whether the person read some of
it vs. whether the person read all of it vs.  whether the person
really understand it vs. whether the person has therefore agreed to
certain assumptions implicit in it.

(Consider a message that says "If you read this and don't respond,
I'll assume you agree to a 5% pay cut".  There is *no way* it would be
semantically useful for the sender of that message to know whether the
recipient has read it, because the sender is making an unreasonable
request of the recipient; the recipient is entirely within his rights
to *read* and *understand* the message, yet choose to not comply, and
how he expressed noncompliance can include not responding, which is
*not* the same as agreeing to a 5% pay cut, regardless of what the
sender presumed.  So any system that promises "will tell you whether
recipient has read the message" is a dangerous one IMO, because it
makes false promises surrounding the semantic confusion over the
meaning of the word "read".)

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