Ned.
Preface: My goal for this sort of exchange is to have a community
consensus for precise language and usage. The lack of this is what
motivated the architecture document. So I'm happy to occupy my familiar
position, holding a minority-of-one view, since I don't see anyone else
sharing it.
That said, it seems worth pursuing a bit further.
POP really does finally delivery,
nfmc> No, it really does no such thing. Final delivery is a well defined action
that
nfmc> 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.
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.
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
module was either a UA or an MTA. Posting and Delivering were the
actions between them.
In any event, POP was definitely for _moving_ messages from the server
to the client. 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
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.
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.
"moving" messages from upstream to
downstream -- to choose some neutral terms. By contrast, IMAP does
"copying" from upstream to downstream. That is, POP changes where
the message actually resides. It is eliminated from the upstream.
nfmc> Not necessarily. POP can be used in a variety of ways,
I said that in my original note.
Not convinced? Consider: If the distance between the MDA and the MS
(e.g., in the case of SMTP) can't be traversed (due to a disk full
situation, for instance), a DSN is returned to the sender.
... Neither POP nor IMAP have such responsibilities. They aren't
part of that bit of the architecture.
nfmc> Which is why all the original work on so-called "timely delivery" in the
FAX WG
nfmc> never panned out.
First of all, folks seem to be missing my distinction between POP's
original intent versus current usage.
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.
Second, the reason I stopped trying to specify timely delivery was that
the entire Internet Mail service model has no such concept and the only
way to retrofit it was increasingly looking like it needed to create a
real-time, end-to-end link.
In any event, this thread was started with the hope of getting
convergence on the diagram. Comments about choices and preferences for
it would be helpful.
d/
--
Dave Crocker <mailto:dcrocker(_at_)brandenburg(_dot_)com>
Brandenburg InternetWorking <http://www.brandenburg.com>
Sunnyvale, CA USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>