Re: MS vs. pop and imap

[[e-mail]]

> > No, it really does no such thing. Final delivery is a well defined action that
> > takes place before POP comes into the picture.

> As I said, that is the current view, yes.  However it is not the
> original view of its role.

While the historical role may be interesting in an academic sense, I have to
say I don't regard it as particularly relevant to the current exercise, which
is to document the current architecture, not one that's lost in the mists of
time, assuming it ever existed at all.

> The very first POP specifications used the word "access", so that would
> seem to support the position that delivery is pre-POP. However those
> documents did not really talk about email models and no one was trying
> to be so precise with the model and terminology, back then.

Even if I were to grant that ancient POP specifications are relevant (I don't),
they do not in fact support the reading you claim. For example, the
introduction to RFC 918 states:

  The intent of the Post Office Protocol (POP) is to allow a user's workstation
  to access mail from a mailbox server. It is expected that mail will be posted
  from the workstation to the mailbox server via the Simple Mail Transfer
  Protocol (SMTP). For further information see RFC-821 [1] and RFC-822 [2].

To be sure, the word "access" is used here, but in the context of "access to a
mailbox server". Not "access to a delivery agent", "access to a message queue",
or anything similar. And the term "delivery" was in use at the time - it
appears throughout RFC 821, of course.

> Worse, the model did not have the concept of a message store, as an
> independent component, so it was difficult to talk about this point.

A mailbox server along with a collection of mailboxes is pretty darned close
IMO. So the concept in some form dates back to at least 1984 in the RFC series.

> A
> module was either a UA or an MTA. Posting and Delivering were the
> actions between them.

The word "deliver" does not appear in RFC 918. You'd think that if POP was
intended to be a delivery process the word would have come up at least once.

> In any event, POP was definitely for _moving_ messages from the server
> to the client.

Not exclusively it isn't. Again, if it were the option to leave mail on the
server would not exist. Instead there would be some form of transactional
handoff and there would be no need for unique identifers so clients
can tell what messages they have downloaded.

> Note that the current spec observes the change/addition
> of retention on the server:

> rfc1939> 8. Scaling and Operational Considerations
> rfc1939>
> rfc1939>    Since some of the optional features described above were added to the
> rfc1939>    POP3 protocol, experience has accumulated in using them in large-
> rfc1939>    scale commercial post office operations where most of the users are
> rfc1939>    unrelated to each other.  In these situations and others, users and
> rfc1939>    vendors of POP3 clients have discovered that the combination of using
> rfc1939>    the UIDL command and not issuing the DELE command can provide a weak
> rfc1939>    version of the "maildrop as semi-permanent repository" functionality

The optional features weren't added to make things like leaving mail on the
server possible. The fact of the matter is that these  things were being done
basically from the get-go. The problem is that without UIDL it can only be done
badly. UIDL makes it possible to do leave mail on server "well".

> As for the question of "delivery" versus "access" in the sense that we
> mean it today, going back to by RFC1081 (1988):

> rfc1081> Introduction
> rfc1081>
> rfc1081>    On certain types of smaller nodes in the Internet it is often
> rfc1081>    impractical to maintain a message transport system (MTS).  For
> rfc1081>    example, a workstation may not have sufficient resources (cycles,
> rfc1081>    disk space) in order to permit a SMTP server and associated local
> rfc1081>    mail delivery system to be kept resident and continuously running.
> rfc1081>    Similarly, it may be expensive (or impossible) to keep a personal
> rfc1081>    computer interconnected to an IP-style network for long amounts of
> rfc1081>    time (the node is lacking the resource known as "connectivity").
> rfc1081>
> rfc1081>    Despite this, it is often very useful to be able to manage mail on
> rfc1081>    these smaller nodes, and they often support a user agent (UA) to aid
> rfc1081>    the tasks of mail handling.

Nothing here says or even implies that POP is going to take over the task of
performing final delivery.

> and

> rfc1081> The POP and the Split-UA model
> rfc1081>
> rfc1081>    The underlying paradigm in which the POP3 functions is that of a
> rfc1081>    split-UA model.  The POP3 client host, being a remote PC based
> rfc1081>    workstation, acts solely as a client to the message transport system.
> rfc1081>    It does not provide delivery/authentication services to others.

> That last line is the only place we get a statement that has a statement
> involving the model as precisely as we are using it now.

See above. There are statements as far back as RFC 918 that describe something
quite close to the current model.

> > Which is why all the original work on so-called "timely delivery" in the FAX WG
> > never panned out.

> First of all, folks seem to be missing my distinction between POP's
> original intent versus current usage.

On the contrary, I see the distinction you're attempting to make. I just don't
buy it and even if I did buy it I don't think it is particularly relevant. The
intent of POP was explicitly stated almost 20 years ago to access mailboxes on
a mailbox server. And most of the implementations of POP since then have been
one of a server that sits on top of a bunch of mailboxes - exactly what
RFC 918 talked about and one form of the things we now call "message
stores".

> And the reference to the fax work is both ironic and wrong.  First, the
> fax effort underscored the problem with having the DSN mechanism stop
> before POP and the need to have POP more capable in the role of
> effecting delivery.

I never said it wasn't a problem. However, it is a problem precisely because
POP wasn't designed for the use the fax folks wanted to put it to, and it is
much harder than it first appears to change it.

In any case, I believe the diagram Cyrus proposed is pretty much on target.

				Ned