Re: MS vs. pop and imap
Dave Crocker <dhc@dcrocker.net> Sun, 30 May 2004 16:50 UTC
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4UGodZY037445; Sun, 30 May 2004 09:50:39 -0700 (PDT) (envelope-from owner-ietf-smtp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4UGodGa037444; Sun, 30 May 2004 09:50:39 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smtp@mail.imc.org using -f
Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4UGocuD037438 for <ietf-smtp@imc.org>; Sun, 30 May 2004 09:50:38 -0700 (PDT) (envelope-from dhc@dcrocker.net)
Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i4UGoaT31390; Sun, 30 May 2004 09:50:36 -0700
Date: Sun, 30 May 2004 09:50:32 -0700
From: Dave Crocker <dhc@dcrocker.net>
Reply-To: Dave Crocker <dcrocker@brandenburg.com>
Organization: Brandenburg InternetWorking
X-Priority: 3 (Normal)
Message-ID: <1899927310.20040530095032@brandenburg.com>
To: ned.freed@mrochek.com
CC: Pete Resnick <presnick@qualcomm.com>, Chris Newman <Chris.Newman@sun.com>, ietf-smtp@imc.org
Subject: Re: MS vs. pop and imap
In-Reply-To: <01LAP28BIA9U00005R@mauve.mrochek.com>
References: <933985834.20040515013625@brandenburg.com> <2147483647.1084809195@nifty-jr.west.sun.com> <756569575.20040529113229@brandenburg.com> <p07001107bcdebe6a41d8@[216.43.25.67]> <01LAP28BIA9U00005R@mauve.mrochek.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-smtp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smtp/mail-archive/>
List-ID: <ietf-smtp.imc.org>
List-Unsubscribe: <mailto:ietf-smtp-request@imc.org?body=unsubscribe>
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@brandenburg.com> Brandenburg InternetWorking <http://www.brandenburg.com> Sunnyvale, CA USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>
- Re: MS vs. pop and imap Eric A. Hall
- Re: Internet Mail Architecture draft Valdis.Kletnieks
- Re: MS vs. pop and imap Cyrus Daboo
- Re: MS vs. pop and imap ned+ietf-smtp
- Re: MS vs. pop and imap Dave Crocker
- Re: MS vs. pop and imap (alternate response) Dave Crocker
- Re: MS vs. pop and imap (alternate response) Hector Santos
- Re: MS vs. pop and imap (alternate response) Pete Resnick
- Re: MS vs. pop and imap Eric A. Hall
- Re: MS vs. pop and imap (alternate response) Cyrus Daboo
- Re: MS vs. pop and imap (alternate response) Pete Resnick
- Re: MS vs. pop and imap ned+ietf-smtp
- Re: MS vs. pop and imap (alternate response) Dave Crocker
- Re: MS vs. pop and imap Pete Resnick
- Re: MS vs. pop and imap Dave Crocker
- Re: MS vs. pop and imap ned+ietf-smtp
- Re: MS vs. pop and imap Hector Santos
- Re: MS vs. pop and imap Cyrus Daboo
- Re: MS vs. pop and imap Pete Resnick
- Re: Internet Mail Architecture draft Eric A. Hall
- Re: Internet Mail Architecture draft Dave Crocker
- Re: MS vs. pop and imap Eric A. Hall
- Re: Internet Mail Architecture draft Eric A. Hall
- MS vs. pop and imap Dave Crocker
- Re: Internet Mail Architecture draft Cyrus Daboo
- Re: Internet Mail Architecture draft Dave Crocker
- Re: Internet Mail Architecture draft Dave Crocker
- Re: Internet Mail Architecture draft Eric A. Hall
- Re: Internet Mail Architecture draft Chris Newman
- Re: Internet Mail Architecture draft Dave Crocker
- Re: Internet Mail Architecture draft Paul Overell
- Internet Mail Architecture draft Dave Crocker
- Re: MS vs. pop and imap Keith Moore
- Re: MS vs. pop and imap Valdis.Kletnieks
- Re: MS vs. pop and imap (alternate response) Dave Crocker
- Re: MS vs. pop and imap (alternate response) Tony Finch
- Re: MS vs. pop and imap (alternate response) Dave Crocker
- Re: MS vs. pop and imap Tony Finch
- Re: MS vs. pop and imap Tony Finch
- Re: MS vs. pop and imap (alternate response) Tony Finch
- Re: MS vs. pop and imap Dave Crocker
- Re: Internet Mail Architecture draft -- consensus… Richard O. Hammer
- Re: MS vs. pop and imap John C Klensin