Received: by ns.secondary.com (8.9.3/8.9.3) id JAA28192 for ietf-pop3ext-bks; Tue, 28 Dec 1999 09:16:45 -0800 (PST) Received: from demo.esys.ca (demo.esys.ca [207.167.22.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA28188 for ; Tue, 28 Dec 1999 09:16:43 -0800 (PST) Received: from galileo.esys.ca (c12933-001.powersurfr.com [24.108.1.109]) by demo.esys.ca (2.0.4/SMS 2.0.4-beta-5) with ESMTP id KAA26781; Tue, 28 Dec 1999 10:21:21 -0700 From: Steve Hole Date: Tue, 28 Dec 1999 10:22:19 -0700 To: Alexey Melnikov Subject: Re: Survey : What clients/servers support CAPA? Cc: POP3 Extensions Mailing List In-Reply-To: <385D5287.23558E0@messagingdirect.com> References: <385D5287.23558E0@messagingdirect.com> Message-ID: X-Mailer: Execmail for Linux 5.3 b1 Build (1) -- Evaluation Copy MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Sender: owner-ietf-pop3ext@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Sun, 19 Dec 1999 14:47:51 -0700 Alexey Melnikov wrote: > I am going to create another web page, that list POP3 extensions > supported by different clients/servers. > > The starting list: > > Clients that supports CAPA: > > Eudora, > Execmail > > Servers that supports CAPA: > > QPopper, > CMU POP3, > M-Store POP3 (formerly SMS) I believe that a subset of this information may be available on the IMC website. Anything new that is collected in this forum should actually be posted to the IMC website so that we maintain the "one true location" for information. Cheers. --- Steve Hole Messaging Direct Mailto:Steve.Hole@MessagingDirect.com Phone: 780-424-4922 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id EAA24734 for ietf-pop3ext-bks; Fri, 24 Dec 1999 04:30:17 -0800 (PST) Received: from mystic.false.com (root@false.com [198.65.171.171]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA24730 for ; Fri, 24 Dec 1999 04:30:15 -0800 (PST) Received: from false.com (root@false.com [198.65.171.171]) by mystic.false.com (8.9.3/8.9.3) with ESMTP id GAA03005 for ; Fri, 24 Dec 1999 06:34:16 -0600 Received: (from solar@localhost) by false.com (8.8.5/8.8.5) id PAA03404 for ietf-pop3ext@imc.org; Fri, 24 Dec 1999 15:24:32 +0300 From: Solar Designer Message-Id: <199912241224.PAA03404@false.com> Subject: RFC 2449: clarifications needed To: ietf-pop3ext@imc.org Date: Fri, 24 Dec 1999 15:24:31 +0300 (MSK) X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-pop3ext@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi, As this list is once again active, I've decided to post my thoughts and a few questions on the changes to POP3 defined by RFC 2449. 1. "This specification increases the length restrictions on commands and parameters imposed by RFC 1939. The maximum length of a command is increased from 47 characters (4 character command, single space, 40 character argument, CRLF) to 255 octets, including the terminating CRLF." This looks like a misinterpretation of RFC 1939 to me. Here's what it used to say: " Commands in the POP3 consist of a case-insensitive keyword, possibly followed by one or more arguments. All commands are terminated by a CRLF pair. Keywords and arguments consist of printable ASCII characters. Keywords and arguments are each separated by a single SPACE character. Keywords are three or four characters long. Each argument may be up to 40 characters long." Even if POP3 commands defined by RFC 1939 accepted at most one argument (which isn't the case: TOP has two arguments), this doesn't imply that POP3 servers were allowed not to parse longer commands correctly. In particular, I consider a server that processes one long command as two or more short ones not fully RFC 1939 compliant. I was specifically looking for a command length limit in RFC 1939 when developing my POP3 server, and came to the conclusion that there's none, even though this may require extra code. Basically, while I like the fact that a length limit is now defined, I believe that our new RFC is wrong in saying that it "increases" the length restrictions. In reality, RFC 2449 compliant servers are not necessarily fully compliant to RFC 1939: they are now allowed to not process commands longer than 255 octets correctly (in the 1939 sense). 2. RFC 1939 didn't specify that POP3 clients are required to wait for a response before issuing another command. It only said that the client and server exchange commands and responses. The "exchange" doesn't sound like a permission to not support pipelined commands to me, even though there're many (broken) servers that don't and this can be tricky to implement if AUTHORIZATION and TRANSACTION states are implemented with different processes or even physical servers. The addition of the PIPELINING capability effectively makes these old POP3 servers (which didn't support pipelining) RFC compliant. I admit that this one issue isn't very clear. Some might say that "exchange" implies waiting for a response. I would prefer a MUST, though. 3. This requirement with PIPELINING seems to be too strict: "If either the client or server uses blocking writes, it MUST not exceed the window size of the underlying transport layer." Here's my understanding of the related issues: 3.1. Both the server and the client process commands and responses in order, so I don't see any harm in a write blocking on just one end. Implementations may want not to block for some reason, but this is an implementation issue and has nothing to do with the protocol. 3.2. Simply not exceeding the window size doesn't guarantee that a blocking write won't block. There're often more requirements, and these depend on both the underlying protocols (currently, TCP with some security layer on top of it), their implementations, and the OS. 3.3. It is often not possible for an application to know if a write would exceed the window size. POP3 clients can assume that a write would likely not block if it doesn't exceed a certain size after all responses to a previous group of commands have been received. I don't know of a way to use such an approach for POP3 servers, as command responses don't get acknowledged on the application layer. RFC 2197 ("SMTP Service Extension for Command Pipelining") explains the real reason behind a similar requirement: avoiding a deadlock condition. If the client blocks on a command write, it won't be able to read responses off the socket, so, once the kernel buffer fills up, it may not acknowledge new responses coming from the server. The write on the server may then block as well. To solve this problem, it seems to be enough to ensure that writes don't block on the client end only. This is what RFC 2197 requires. Besides, is there any useful work for a POP3 server to be done if it would otherwise block on a write of a response? Reading all commands off the socket immediately (to be reasonably sure the client won't have a need to block) would potentially require an unlimited storage. This is not good anyway. Finally, it is not blocking writes that cause the problem -- it is blocking _anywhere_ and not reading responses off the socket in time that does. The fact that a client doesn't use blocking writes or makes sure they don't block doesn't yet imply that it doesn't have the deadlock problem. I suggest that the requirement be relaxed to apply to POP3 clients only, and the reasoning behind it explained in the RFC. I'll appreciate any comments on the thoughts above. I am going to add CAPA support into my POP3 server, but would like to make these issues clear first. Current version of the server can be found at: http://www.openwall.com/popa3d/ Signed, Solar Designer Received: by ns.secondary.com (8.9.3/8.9.3) id KAA24693 for ietf-pop3ext-bks; Mon, 20 Dec 1999 10:31:39 -0800 (PST) Received: from demo.esys.ca (demo.esys.ca [207.167.22.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA24688 for ; Mon, 20 Dec 1999 10:31:38 -0800 (PST) Received: from messagingdirect.com (dhcp198-53.esys.ca [198.161.92.53]) by demo.esys.ca (2.0.4/SMS 2.0.4-beta-5) with ESMTP id LAA14679; Mon, 20 Dec 1999 11:35:46 -0700 Message-ID: <385E7645.A14EB093@messagingdirect.com> Date: Mon, 20 Dec 1999 11:32:37 -0700 From: Alexey Melnikov X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: POP3 Extensions Mailing List Subject: Re: Survey : What clients/servers support CAPA? References: <385D5287.23558E0@messagingdirect.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-pop3ext@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: UW-2000 will support CAPA according to Mark Crispin Alexey Received: by ns.secondary.com (8.9.3/8.9.3) id OAA18654 for ietf-pop3ext-bks; Sun, 19 Dec 1999 14:33:44 -0800 (PST) Received: from demo.esys.ca (demo.esys.ca [207.167.22.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA18650 for ; Sun, 19 Dec 1999 14:33:42 -0800 (PST) Received: from messagingdirect.com (2-042-edm.dial.worldgate.ca [207.167.2.42]) by demo.esys.ca (2.0.4/SMS 2.0.4-beta-5) with ESMTP id PAA12756; Sun, 19 Dec 1999 15:37:46 -0700 Message-ID: <385D5D7E.E758698E@messagingdirect.com> Date: Sun, 19 Dec 1999 15:34:38 -0700 From: Alexey Melnikov X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: POP3 Extensions Mailing List Subject: Re: Survey : What clients/servers support CAPA? References: <385D5287.23558E0@messagingdirect.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-pop3ext@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The information that particular product DOESN'T support CAPA command is also welcomed. Alexey Melnikov wrote: > > I am going to create another web page, that list POP3 extensions > supported by different clients/servers. > > The starting list: > > Clients that supports CAPA: > > Eudora, > Execmail > > Servers that supports CAPA: > > QPopper, > CMU POP3, > M-Store POP3 (formerly SMS) > > Alexey Received: by ns.secondary.com (8.9.3/8.9.3) id OAA18366 for ietf-pop3ext-bks; Sun, 19 Dec 1999 14:03:56 -0800 (PST) Received: from demo.esys.ca (demo.esys.ca [207.167.22.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA18362 for ; Sun, 19 Dec 1999 14:03:55 -0800 (PST) Received: from messagingdirect.com (2-042-edm.dial.worldgate.ca [207.167.2.42]) by demo.esys.ca (2.0.4/SMS 2.0.4-beta-5) with ESMTP id PAA12636; Sun, 19 Dec 1999 15:07:58 -0700 Message-ID: <385D5287.23558E0@messagingdirect.com> Date: Sun, 19 Dec 1999 14:47:51 -0700 From: Alexey Melnikov X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: POP3 Extensions Mailing List Subject: Survey : What clients/servers support CAPA? Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-pop3ext@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I am going to create another web page, that list POP3 extensions supported by different clients/servers. The starting list: Clients that supports CAPA: Eudora, Execmail Servers that supports CAPA: QPopper, CMU POP3, M-Store POP3 (formerly SMS) Alexey Received: by ns.secondary.com (8.9.3/8.9.3) id OAA15005 for ietf-pop3ext-bks; Fri, 17 Dec 1999 14:48:50 -0800 (PST) Received: from ckmso1.proxy.att.com (ckmso1.att.com [12.20.58.69]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA15000 for ; Fri, 17 Dec 1999 14:48:49 -0800 (PST) Received: from dns.maillennium.att.com ([135.25.114.99]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-2.2) with ESMTP id RAA29737 for ; Fri, 17 Dec 1999 17:51:53 -0500 (EST) Received: from att.com ([135.197.90.137]) by maillennium.att.com (labmail) with SMTP id <1999121722492909920993bpe>; Fri, 17 Dec 1999 22:49:29 +0000 Message-ID: <385ABE3A.9043126B@att.com> Date: Fri, 17 Dec 1999 17:50:34 -0500 From: Tony Hansen Organization: AT&T Laboratories X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Anders Rundegren CC: ietf-pop3ext@imc.org Subject: Re: POP3 "resume download" extension References: <3859746C.3228F180@rundegren.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-pop3ext@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Anders Rundegren wrote: > > I've had some thoughts about an extension to POP3 that will let you > resume a download of an interrupted transfer. These days people tend to > send each other messages with large attachment, 2-3Mb is not that > uncommon. Many clients connecting to their ISP, or even the ISP itself, > have their modems improperly setup which causes a flaky phoneline, > resulting in a premature disconnect. > > At present, these messages will have to be re-downloaded from scratch > taking a lot of unnecessary bandwidth from the ISP, not to mention > resources within the system itself. Since a majority of the ISPs today > are still using POP3, as opposed to IMAP (mostly due to the reduced > diskspace required when serving a huge numbers of users), I think this > might be a good idea. An interesting thing about IMAP is that is fully supports the model of message management that POP provides where messages are moved from the server to the local machine and deleted from the server. However, very few clients are built to support using IMAP in that fashion. They almost all assume that if you're using IMAP, you only want to keep your messages remotely. If an IMAP server were to disallow remote folders, you'd have essentially the equivalent of a fancy POP server. And it would have no higher diskspace requirements than any POP server would require. Tony Hansen tony@att.com Received: by ns.secondary.com (8.9.3/8.9.3) id NAA13858 for ietf-pop3ext-bks; Fri, 17 Dec 1999 13:40:10 -0800 (PST) Received: from jittlov.qualcomm.com (jittlov.qualcomm.com [129.46.50.79]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA13852 for ; Fri, 17 Dec 1999 13:40:09 -0800 (PST) Received: from lombok (llundbla.qualcomm.com [129.46.219.60]) by jittlov.qualcomm.com (8.8.5/1.4/8.7.2/1.15) with ESMTP id NAA01386; Fri, 17 Dec 1999 13:43:53 -0800 (PST) Message-Id: <4.2.2.19991217133728.00b51710@hotsun.qualcomm.com> X-Sender: lgl@hotsun.qualcomm.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 17 Dec 1999 13:50:07 -0800 To: "Bonatti, Chris" , Keith Moore From: Laurence Lundblade Subject: Re: POP3 "resume download" extension Cc: "ietf-pop3ext@imc.org" In-Reply-To: <3859D2E4.2B02DDA9@ieca.com> References: <199912171506.KAA19276@astro.cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-pop3ext@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 09:06 PM 12/17/99 +0500, Bonatti, Chris wrote: >Keith Moore wrote: > > > > Thinking about pipelining, though, how does this sound: POP3 is > normally a > > > half-duplex-like dialog. Suppose we allow an allowed a received command > > > sequence (like maybe "!NEXT") to queue an interrupt of the download at > > > the next chunk. > > > > If you're suggesting that servers do out-of-order command processing, > > I don't think that's the way to go. > > > >No, I didn't really mean out-of-order command processing. What I meant is >that >there would be a recurring state at the end of every chunk in which the server >checks to see whether it has received an "interrupt" command. If it has, it >could skip to the start of the next message. If it hasn't, it would continue >with the next chunk. So the client wouldn't request the chunks. The server would just send in chunks and look for aborts every once in a while. If you're doing one RETR after another and you're pipelining you're going to have at least one command (a RETR) waiting at the in queue on the server to be processed. If you send an ABORT it will be behind the RETR in the queue so you'd have to process it out of order. Processing out of order would be bad because it would make the server much more difficult to implement. POP servers can be very simple now. Being able to request chunks with a RETR command would help aborts for long messages. It seems in an ideal chunked implementation the client would have some idea of the bytes/sec capacity of pipe is and only have requests for enough bytes to fill the pipe outstanding. That way you only wait on the order of one round trip for an abort. Since the size of a message is typically much larger than the number of bytes to fill the byte, chunking requests win. How easy it would be to get to an ideal implementation is another matter. Pipes are very bursty and through put is hard to characterize. I suspect one would still be able to get much faster abort times with chunked requests without compromising overall download speed though. LL Received: by ns.secondary.com (8.9.3/8.9.3) id KAA11202 for ietf-pop3ext-bks; Fri, 17 Dec 1999 10:05:35 -0800 (PST) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA11198 for ; Fri, 17 Dec 1999 10:05:33 -0800 (PST) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id NAA19725; Fri, 17 Dec 1999 13:08:30 -0500 (EST) Message-Id: <199912171808.NAA19725@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Bonatti, Chris" cc: Keith Moore , "ietf-pop3ext@imc.org" Subject: Re: POP3 "resume download" extension In-reply-to: Your message of "Fri, 17 Dec 1999 21:06:28 +0500." <3859D2E4.2B02DDA9@ieca.com> Date: Fri, 17 Dec 1999 13:08:30 -0500 Sender: owner-ietf-pop3ext@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > > > Thinking about pipelining, though, how does this sound: POP3 is normally a > > > half-duplex-like dialog. Suppose we allow an allowed a received command > > > sequence (like maybe "!NEXT") to queue an interrupt of the download at > > > the next chunk. > > > > If you're suggesting that servers do out-of-order command processing, > > I don't think that's the way to go. > > > > No, I didn't really mean out-of-order command processing. What I meant is > that there would be a recurring state at the end of every chunk in > which the server checks to see whether it has received an "interrupt" > command. I think there would be significant pushback against changes to the basic POP request-response command structure...it would be difficult to retro-fit existing servers to support it and once you get away from simple request-response it's fairly easy to introduce silly states. (e.g.: suppose a client wants to issue several commands at once without waiting for a response, and then later on needs to interrupt a transfer. by the time the server gets the interrupt, it's working on a different transfer already, and it interrupts the wrong one.) Keith Received: by ns.secondary.com (8.9.3/8.9.3) id KAA11177 for ietf-pop3ext-bks; Fri, 17 Dec 1999 10:03:02 -0800 (PST) Received: from demo.esys.ca (demo.esys.ca [207.167.22.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA11173 for ; Fri, 17 Dec 1999 10:03:01 -0800 (PST) Received: from messagingdirect.com (dhcp198-53.esys.ca [198.161.92.53]) by demo.esys.ca (2.0.4/SMS 2.0.4-beta-5) with ESMTP id LAA08561; Fri, 17 Dec 1999 11:06:46 -0700 Message-ID: <385A7AFD.A8B6718B@messagingdirect.com> Date: Fri, 17 Dec 1999 11:03:42 -0700 From: Alexey Melnikov X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Laurence Lundblade CC: ietf-pop3ext@imc.org Subject: Re: POP3 "resume download" extension References: <3859746C.3228F180@rundegren.com> <4.2.2.19991217095326.00c04230@hotsun.qualcomm.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-pop3ext@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Laurence Lundblade wrote: > We clearly don't want to make POP3 into IMAP4 for many many reasons :-) > > One thing Chris Newman and myself were discussing a bit was a profile of > IMAP that just supported the features needed to do off-line mode in IMAP. > The idea is that these servers would address the problems ISP's have with > deploying full IMAP (performance and resource issues, and complexity for > set up, the end user and customer support). I will vote in favour of this proposal! > Then we could create a pop extension that means "don't use POP, offline > IMAP supported at port XXX" and make the transition seamless for the user. Alexey Received: by ns.secondary.com (8.9.3/8.9.3) id JAA10959 for ietf-pop3ext-bks; Fri, 17 Dec 1999 09:48:56 -0800 (PST) Received: from jittlov.qualcomm.com (jittlov.qualcomm.com [129.46.50.79]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA10955 for ; Fri, 17 Dec 1999 09:48:54 -0800 (PST) Received: from lombok (llundbla.qualcomm.com [129.46.219.60]) by jittlov.qualcomm.com (8.8.5/1.4/8.7.2/1.15) with ESMTP id JAA01864; Fri, 17 Dec 1999 09:52:25 -0800 (PST) Message-Id: <4.2.2.19991217095326.00c04230@hotsun.qualcomm.com> X-Sender: lgl@hotsun.qualcomm.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 17 Dec 1999 09:59:41 -0800 To: Alexey Melnikov , Anders Rundegren From: Laurence Lundblade Subject: Re: POP3 "resume download" extension Cc: ietf-pop3ext@imc.org In-Reply-To: <38597DC0.E4AD59B9@messagingdirect.com> References: <3859746C.3228F180@rundegren.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-pop3ext@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 05:03 PM 12/16/99 -0700, Alexey Melnikov wrote: >I understand the reasons for proposing such extension, but the >functionality is already in IMAP4 protocol. My question is : do you want >to make IMAP4 from POP3? > >Alexey We clearly don't want to make POP3 into IMAP4 for many many reasons :-) One thing Chris Newman and myself were discussing a bit was a profile of IMAP that just supported the features needed to do off-line mode in IMAP. The idea is that these servers would address the problems ISP's have with deploying full IMAP (performance and resource issues, and complexity for set up, the end user and customer support). Then we could create a pop extension that means "don't use POP, offline IMAP supported at port XXX" and make the transition seamless for the user. LL Received: by ns.secondary.com (8.9.3/8.9.3) id IAA09232 for ietf-pop3ext-bks; Fri, 17 Dec 1999 08:02:45 -0800 (PST) Received: from smtp-a.capu.net (IDENT:root@smtp-a.capu.net [205.177.76.122]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA09228 for ; Fri, 17 Dec 1999 08:02:43 -0800 (PST) Received: from ieca.com (mva-aa-029.capu.net [207.226.159.29]) by smtp-a.capu.net (8.9.3/8.9.3) with ESMTP id LAA16035; Fri, 17 Dec 1999 11:06:35 -0500 Message-ID: <3859D2E4.2B02DDA9@ieca.com> Date: Fri, 17 Dec 1999 21:06:28 +0500 From: "Bonatti, Chris" Organization: IECA, Inc. X-Mailer: Mozilla 4.51 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Keith Moore CC: "ietf-pop3ext@imc.org" Subject: Re: POP3 "resume download" extension References: <199912171506.KAA19276@astro.cs.utk.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-pop3ext@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Keith Moore wrote: > > Thinking about pipelining, though, how does this sound: POP3 is normally a > > half-duplex-like dialog. Suppose we allow an allowed a received command > > sequence (like maybe "!NEXT") to queue an interrupt of the download at > > the next chunk. > > If you're suggesting that servers do out-of-order command processing, > I don't think that's the way to go. > No, I didn't really mean out-of-order command processing. What I meant is that there would be a recurring state at the end of every chunk in which the server checks to see whether it has received an "interrupt" command. If it has, it could skip to the start of the next message. If it hasn't, it would continue with the next chunk. This approach has the advantage that both the client and server need do nothing at all if the download is to continue. I just don't know how hard the "listenening" is for most server implementations. Chris Received: by ns.secondary.com (8.9.3/8.9.3) id HAA08196 for ietf-pop3ext-bks; Fri, 17 Dec 1999 07:03:27 -0800 (PST) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA08192 for ; Fri, 17 Dec 1999 07:03:26 -0800 (PST) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id KAA19276; Fri, 17 Dec 1999 10:06:22 -0500 (EST) Message-Id: <199912171506.KAA19276@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Bonatti, Chris" cc: Keith Moore , "ietf-pop3ext@imc.org" Subject: Re: POP3 "resume download" extension In-reply-to: Your message of "Fri, 17 Dec 1999 19:32:26 +0500." <3859BCD9.D41719E7@ieca.com> Date: Fri, 17 Dec 1999 10:06:22 -0500 Sender: owner-ietf-pop3ext@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Thinking about pipelining, though, how does this sound: POP3 is normally a > half-duplex-like dialog. Suppose we allow an allowed a received command > sequence (like maybe "!NEXT") to queue an interrupt of the download at > the next chunk. If you're suggesting that servers do out-of-order command processing, I don't think that's the way to go. The goal of pipelining chunk requests is to get maximum download speed while still having an early abort capability. Say a client is trying to download a 1MB message in 100K chunks. If it has to get the response from each chunk request before asking for the next the next chunk, there's a round-trip delay after every chunk which could take as long as downloading 100K of data. So having partial retrieve could make the overall download take twice as long. OTOH, if the client can queue ahead several PRET requests then it can make sure that there is always a request outstanding in the server's queue...so there is no waiting. but it can still abort a download within the time it takes for the server to deal with the number of queued-ahead requests ... which is much better than waiting for the entire message and (if tuned right) also better than closing and reopening the connection. maybe what is needed are two "special cookies" for PRET: cookie # means "start at beginning of message" cookie @ means "continue transfer following the last PRET" however, this adds some state to the server. what happens if a client is displaying multiple messages from the same server in different windows, and the user keeps scrolling the windows around? the client (having initially only downloaded enough of each message to display the first page or two of each) might then want to interleave PRETs from one message with PRETs from another. Keith Keith Received: by ns.secondary.com (8.9.3/8.9.3) id GAA07661 for ietf-pop3ext-bks; Fri, 17 Dec 1999 06:28:36 -0800 (PST) Received: from smtp-a.capu.net (IDENT:root@smtp-a.capu.net [205.177.76.122]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA07657 for ; Fri, 17 Dec 1999 06:28:34 -0800 (PST) Received: from ieca.com (mva-aa-033.capu.net [207.226.159.33]) by smtp-a.capu.net (8.9.3/8.9.3) with ESMTP id JAA11050; Fri, 17 Dec 1999 09:32:26 -0500 Message-ID: <3859BCD9.D41719E7@ieca.com> Date: Fri, 17 Dec 1999 19:32:26 +0500 From: "Bonatti, Chris" Organization: IECA, Inc. X-Mailer: Mozilla 4.51 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Keith Moore CC: "ietf-pop3ext@imc.org" Subject: Re: POP3 "resume download" extension References: <199912171410.JAA18906@astro.cs.utk.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-pop3ext@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Keith Moore wrote: > what I had in mind was being able to download a message in chunks with a > fairly easy way for the client to say 'stop sending any more chunks'. > having the client close and reopen the connection is slow and wasteful. > so if the client can ask for (say) the first 50k, then the second 50k, > etc. and the user wants to stop downloading after a few seconds, then > all the client has to do is stop asking for more chunks. but it seems > like you do want to be able to pipeline it. > Yes, I see what you mean. I agree that punting the connection seems inefficient. You could also do such a thing as a RETR extension, but it would be sufficiently incompatible that it wouldn't really be any different from a separate command. Pipelining this sounds hard. It would be cleaner to check the size of the messages before beginning the RETR, thereby deciding what exceed your threshold. However, I suspect that a user wouldn't always see it that way. Sometimes you end up on a clogged channel or a slow connection that you don't expect. So we need to look at the problem strictly from the user abort point of view. Thinking about pipelining, though, how does this sound: POP3 is normally a half-duplex-like dialog. Suppose we allow an allowed a received command sequence (like maybe "!NEXT") to queue an interrupt of the download at the next chunk. This would require the server to at least nominally *listen* while sending, but since it would not have to process it until the next chunk-boundary was reached the listening would not be too onerous. How difficult would something like this be to implement? Chris Received: by ns.secondary.com (8.9.3/8.9.3) id GAA07360 for ietf-pop3ext-bks; Fri, 17 Dec 1999 06:07:50 -0800 (PST) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA07356 for ; Fri, 17 Dec 1999 06:07:49 -0800 (PST) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id JAA18906; Fri, 17 Dec 1999 09:10:43 -0500 (EST) Message-Id: <199912171410.JAA18906@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Bonatti, Chris" cc: Keith Moore , Anders Rundegren , Alexey Melnikov , "ietf-pop3ext@imc.org" Subject: Re: POP3 "resume download" extension In-reply-to: Your message of "Fri, 17 Dec 1999 19:04:32 +0500." <3859B650.BDB07B0C@ieca.com> Date: Fri, 17 Dec 1999 09:10:43 -0500 Sender: owner-ietf-pop3ext@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > > if you do define an extension for partial message retrieval I think it > > should allow partial message retrieval (e.g. byte count) rather than > > just resume. that way, you don't have to drop a connection to > > get the server to stop sending you a message. I also suspect it should > > be a different command rather than an extension to RETR - with the latter > > approach my guess is you're likely to run into some compatibility problems > > with old servers. > > > > Keith, > > This also sounds okay, but it certainly could complicate deployment. What > would the benefit be if the assumption (for a large message) is a binary > attachment? Half a message just wouldn't do anybody much good. what I had in mind was being able to download a message in chunks with a fairly easy way for the client to say 'stop sending any more chunks'. having the client close and reopen the connection is slow and wasteful. so if the client can ask for (say) the first 50k, then the second 50k, etc. and the user wants to stop downloading after a few seconds, then all the client has to do is stop asking for more chunks. but it seems like you do want to be able to pipeline it. Keith Received: by ns.secondary.com (8.9.3/8.9.3) id GAA07237 for ietf-pop3ext-bks; Fri, 17 Dec 1999 06:01:05 -0800 (PST) Received: from smtp-a.capu.net (IDENT:root@smtp-a.capu.net [205.177.76.122]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA07233 for ; Fri, 17 Dec 1999 06:01:03 -0800 (PST) Received: from ieca.com (mva-aa-119.capu.net [207.226.159.119]) by smtp-a.capu.net (8.9.3/8.9.3) with ESMTP id JAA10573; Fri, 17 Dec 1999 09:04:46 -0500 Message-ID: <3859B650.BDB07B0C@ieca.com> Date: Fri, 17 Dec 1999 19:04:32 +0500 From: "Bonatti, Chris" Organization: IECA, Inc. X-Mailer: Mozilla 4.51 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Keith Moore , Anders Rundegren , Alexey Melnikov CC: "ietf-pop3ext@imc.org" Subject: Re: POP3 "resume download" extension References: <199912170622.BAA02584@astro.cs.utk.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-pop3ext@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Anders Rundegren wrote: > Not at all, this feature wouldn't break POP3's download-and-delete > model, it doesn't change any states on the server either. It's in its > own simplicity just an extension to the RETR command. I don't think > adding this feature would make POP3 close in on the IMAP model. > Anders, I agree that this would be a very useful and simple extension. I would support it's definition. Later, Keith Moore wrote: > if you do define an extension for partial message retrieval I think it > should allow partial message retrieval (e.g. byte count) rather than > just resume. that way, you don't have to drop a connection to > get the server to stop sending you a message. I also suspect it should > be a different command rather than an extension to RETR - with the latter > approach my guess is you're likely to run into some compatibility problems > with old servers. > Keith, This also sounds okay, but it certainly could complicate deployment. What would the benefit be if the assumption (for a large message) is a binary attachment? Half a message just wouldn't do anybody much good. Later still, Alexey Melnikov wrote: > IMAP community spent several years convincing client writers to do this > right. You have to convince POP3 server and client writers that they > must add such functionality to their products. > Alexey, Yes, this is likely to be necessary, but it will either sell or it won't. I don't think that should be a barrier to *defining* the extension. Our servers are full of RFCs and drafts that went nowhere in the final analysis. Personally, I think that this will sell. It provides a measure of "robustness" in a simple package, and there is a great interest in buying stronger, better, etc. Chris --------------------------------------------------------------- | International Electronic Communication Analysts, Inc. | | Christopher D. Bonatti 15309 Turkey Foot Road | | Principal Engineer Darnestown, Md 20878-3640 | | bonattic@ieca.com Tel: 301-208-2349 Fax: 301-208-2379 | --------------------------------------------------------------- Received: by ns.secondary.com (8.9.3/8.9.3) id AAA28604 for ietf-pop3ext-bks; Fri, 17 Dec 1999 00:14:48 -0800 (PST) Received: from demo.esys.ca (demo.esys.ca [207.167.22.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA28599 for ; Fri, 17 Dec 1999 00:14:46 -0800 (PST) Received: from messagingdirect.com (2-109-edm.dial.worldgate.ca [207.167.2.109]) by demo.esys.ca (2.0.4/SMS 2.0.4-beta-5) with ESMTP id BAA07884; Fri, 17 Dec 1999 01:18:34 -0700 Message-ID: <3859F120.434073C2@messagingdirect.com> Date: Fri, 17 Dec 1999 01:15:28 -0700 From: Alexey Melnikov X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: vrs@rampnet.com CC: anders@rundegren.com, ietf-pop3ext@imc.org Subject: Re: POP3 "resume download" extension References: <3859746C.3228F180@rundegren.com> <385A12D2.3BDD279E@rampnet.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-pop3ext@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Yes, i guess this would be a good idea to have this option in POP3. I agree > with Anders that it would not be like IMAP4. Probably i guess we should go ahead > and propose this feature. Don't get me wrong : I agree that proposed extension is useful. (And it would be dead easy to implement the extended RETR in our server, for example.) I just concerned about adding too much advanced functionality to POP3. IMAP community spent several years convincing client writers to do this right. You have to convince POP3 server and client writers that they must add such functionality to their products. Alexey Received: by ns.secondary.com (8.9.3/8.9.3) id WAA21461 for ietf-pop3ext-bks; Thu, 16 Dec 1999 22:19:22 -0800 (PST) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA21457 for ; Thu, 16 Dec 1999 22:19:21 -0800 (PST) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id BAA02584; Fri, 17 Dec 1999 01:22:26 -0500 (EST) Message-Id: <199912170622.BAA02584@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: vrs@rampnet.com cc: Anders Rundegren , "ietf-pop3ext@imc.org" Subject: Re: POP3 "resume download" extension In-reply-to: Your message of "Fri, 17 Dec 1999 05:09:14 GMT." <385A12D2.3BDD279E@rampnet.com> X-SUBJECT-MSG-FROM: "R.Srinivasan" Date: Fri, 17 Dec 1999 01:22:26 -0500 Sender: owner-ietf-pop3ext@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: fwiw, a lot of folks are likely to push back on defining any new extension to pop. there is a feeling that two mail access protocols are too many, and that new effort should be invested into imap rather than pop. but that doesn't mean you shouldn't try, just be aware that you may get some pushback, perhaps enough that it doesn't fly. if you do define an extension for partial message retrieval I think it should allow partial message retrieval (e.g. byte count) rather than just resume. that way, you don't have to drop a connection to get the server to stop sending you a message. I also suspect it should be a different command rather than an extension to RETR - with the latter approach my guess is you're likely to run into some compatibility problems with old servers. but something like PRET (PRET = "partial retrieve") where is not a byte offset but a cookie that is returned from a previous PRET command (if you want to resume here, use this cookie in the next PRET command)...that would allow for different back-end representations. only problem is it doesn't work well for pipelining - you can't send request #N until you've received response #N-1 - but maybe someone will think of something. Keith Received: by ns.secondary.com (8.9.3/8.9.3) id VAA18042 for ietf-pop3ext-bks; Thu, 16 Dec 1999 21:19:46 -0800 (PST) Received: from ns.hyd.rampnet.com ([208.247.183.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA18038 for ; Thu, 16 Dec 1999 21:19:41 -0800 (PST) Received: from ns.hyd.rampnet.com ([208.247.183.98]) by ns.hyd.rampnet.com (8.8.7/8.8.5) with ESMTP id KAA00694; Fri, 17 Dec 1999 10:43:15 +0530 Message-ID: <385A12D2.3BDD279E@rampnet.com> Date: Fri, 17 Dec 1999 05:09:14 +0000 From: "R.Srinivasan" Reply-To: vrs@rampnet.com Organization: Ramp Network (p) Ltd X-Mailer: Mozilla 4.7 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: Anders Rundegren CC: "ietf-pop3ext@imc.org" Subject: Re: POP3 "resume download" extension References: <3859746C.3228F180@rundegren.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-pop3ext@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Anders Rundegren wrote: > I've had some thoughts about an extension to POP3 that will let you > resume a download of an interrupted transfer. These days people tend to > send each other messages with large attachment, 2-3Mb is not that > uncommon. Many clients connecting to their ISP, or even the ISP itself, > have their modems improperly setup which causes a flaky phoneline, > resulting in a premature disconnect. > > At present, these messages will have to be re-downloaded from scratch > taking a lot of unnecessary bandwidth from the ISP, not to mention > resources within the system itself. Since a majority of the ISPs today > are still using POP3, as opposed to IMAP (mostly due to the reduced > diskspace required when serving a huge numbers of users), I think this > might be a good idea. > > I've spent the last week discussing and developing the idea with a few > people, and they are all backing up the idea. I now felt it was time to > take it to this group in order to get a response from a larger group. > > We all came to the conslusion that by giving the RETR command a second > argument specifying the offset of where to start downloading would > probably be the best idea. Also, there was a discussion on wheather an > octet range, (a third argument, specifying where the end of the download > should take place) would be appropriate now that we see a lot more > portable internet devices where bandwidth is scarce. > > A breakdown on savings: > > 1) Less consumption of bandwidth > 2) Less resources used on the servers > 3) ISPs wishing to have this feature will not be forced to deploy an > IMAP server > > Not to mention happier users getting their files faster and cheaper (in > Sweden, and most other countries in Europe, flatrates are just a mere > dream). > > // Anders Rundegren Yes, i guess this would be a good idea to have this option in POP3. I agree with Anders that it would not be like IMAP4. Probably i guess we should go ahead and propose this feature. Srinivasan Received: by ns.secondary.com (8.9.3/8.9.3) id RAA21918 for ietf-pop3ext-bks; Thu, 16 Dec 1999 17:09:08 -0800 (PST) Received: from enterprise.home (IDENT:root@sdu166-203.ppp.algonet.se [195.163.203.166]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA21913 for ; Thu, 16 Dec 1999 17:09:05 -0800 (PST) Received: from rundegren.com (IDENT:sarek@localhost.localdomain [127.0.0.1]) by enterprise.home (8.9.3/8.9.3) with ESMTP id CAA00676; Fri, 17 Dec 1999 02:12:39 +0100 Message-ID: <38598E07.1230EA61@rundegren.com> Date: Fri, 17 Dec 1999 02:12:39 +0100 From: Anders Rundegren X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: Alexey Melnikov CC: ietf-pop3ext@imc.org Subject: Re: POP3 "resume download" extension References: <3859746C.3228F180@rundegren.com> <38597DC0.E4AD59B9@messagingdirect.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-pop3ext@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Anders Rundegren wrote: > > > > I've had some thoughts about an extension to POP3 that will let you > > resume a download of an interrupted transfer. These days people tend to > > send each other messages with large attachment, 2-3Mb is not that > > uncommon. Many clients connecting to their ISP, or even the ISP itself, > > have their modems improperly setup which causes a flaky phoneline, > > resulting in a premature disconnect. > ... > > I understand the reasons for proposing such extension, but the > functionality is already in IMAP4 protocol. My question is : do you want > to make IMAP4 from POP3? > > Alexey Not at all, this feature wouldn't break POP3's download-and-delete model, it doesn't change any states on the server either. It's in its own simplicity just an extension to the RETR command. I don't think adding this feature would make POP3 close in on the IMAP model. // Anders Received: by ns.secondary.com (8.9.3/8.9.3) id QAA20838 for ietf-pop3ext-bks; Thu, 16 Dec 1999 16:02:56 -0800 (PST) Received: from demo.esys.ca (demo.esys.ca [207.167.22.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA20829 for ; Thu, 16 Dec 1999 16:02:54 -0800 (PST) Received: from messagingdirect.com (2-018-edm.dial.worldgate.ca [207.167.2.18]) by demo.esys.ca (2.0.4/SMS 2.0.4-beta-5) with ESMTP id RAA06648; Thu, 16 Dec 1999 17:06:16 -0700 Message-ID: <38597DC0.E4AD59B9@messagingdirect.com> Date: Thu, 16 Dec 1999 17:03:12 -0700 From: Alexey Melnikov X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Anders Rundegren CC: ietf-pop3ext@imc.org Subject: Re: POP3 "resume download" extension References: <3859746C.3228F180@rundegren.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-pop3ext@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Anders Rundegren wrote: > > I've had some thoughts about an extension to POP3 that will let you > resume a download of an interrupted transfer. These days people tend to > send each other messages with large attachment, 2-3Mb is not that > uncommon. Many clients connecting to their ISP, or even the ISP itself, > have their modems improperly setup which causes a flaky phoneline, > resulting in a premature disconnect. ... I understand the reasons for proposing such extension, but the functionality is already in IMAP4 protocol. My question is : do you want to make IMAP4 from POP3? Alexey Received: by ns.secondary.com (8.9.3/8.9.3) id PAA20189 for ietf-pop3ext-bks; Thu, 16 Dec 1999 15:21:48 -0800 (PST) Received: from enterprise.home (IDENT:root@sdu169-200.ppp.algonet.se [195.163.200.169]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA20184 for ; Thu, 16 Dec 1999 15:21:45 -0800 (PST) Received: from rundegren.com (IDENT:sarek@localhost.localdomain [127.0.0.1]) by enterprise.home (8.9.3/8.9.3) with ESMTP id AAA01533; Fri, 17 Dec 1999 00:23:24 +0100 Message-ID: <3859746C.3228F180@rundegren.com> Date: Fri, 17 Dec 1999 00:23:24 +0100 From: Anders Rundegren X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: ietf-pop3ext@imc.org Subject: POP3 "resume download" extension Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-pop3ext@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I've had some thoughts about an extension to POP3 that will let you resume a download of an interrupted transfer. These days people tend to send each other messages with large attachment, 2-3Mb is not that uncommon. Many clients connecting to their ISP, or even the ISP itself, have their modems improperly setup which causes a flaky phoneline, resulting in a premature disconnect. At present, these messages will have to be re-downloaded from scratch taking a lot of unnecessary bandwidth from the ISP, not to mention resources within the system itself. Since a majority of the ISPs today are still using POP3, as opposed to IMAP (mostly due to the reduced diskspace required when serving a huge numbers of users), I think this might be a good idea. I've spent the last week discussing and developing the idea with a few people, and they are all backing up the idea. I now felt it was time to take it to this group in order to get a response from a larger group. We all came to the conslusion that by giving the RETR command a second argument specifying the offset of where to start downloading would probably be the best idea. Also, there was a discussion on wheather an octet range, (a third argument, specifying where the end of the download should take place) would be appropriate now that we see a lot more portable internet devices where bandwidth is scarce. A breakdown on savings: 1) Less consumption of bandwidth 2) Less resources used on the servers 3) ISPs wishing to have this feature will not be forced to deploy an IMAP server Not to mention happier users getting their files faster and cheaper (in Sweden, and most other countries in Europe, flatrates are just a mere dream). // Anders Rundegren Received: by ns.secondary.com (8.9.3/8.9.3) id PAA20147 for ietf-pop3ext-bks; Thu, 16 Dec 1999 15:19:40 -0800 (PST) Received: from enterprise.home (IDENT:root@sdu169-200.ppp.algonet.se [195.163.200.169]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA20143 for ; Thu, 16 Dec 1999 15:19:36 -0800 (PST) Received: from rundegren.com (IDENT:sarek@localhost.localdomain [127.0.0.1]) by enterprise.home (8.9.3/8.9.3) with ESMTP id AAA01533; Fri, 17 Dec 1999 00:23:24 +0100 Message-ID: <3859746C.3228F180@rundegren.com> Date: Fri, 17 Dec 1999 00:23:24 +0100 From: Anders Rundegren X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: ietf-pop3ext@imc.org Subject: POP3 "resume download" extension Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-pop3ext@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I've had some thoughts about an extension to POP3 that will let you resume a download of an interrupted transfer. These days people tend to send each other messages with large attachment, 2-3Mb is not that uncommon. Many clients connecting to their ISP, or even the ISP itself, have their modems improperly setup which causes a flaky phoneline, resulting in a premature disconnect. At present, these messages will have to be re-downloaded from scratch taking a lot of unnecessary bandwidth from the ISP, not to mention resources within the system itself. Since a majority of the ISPs today are still using POP3, as opposed to IMAP (mostly due to the reduced diskspace required when serving a huge numbers of users), I think this might be a good idea. I've spent the last week discussing and developing the idea with a few people, and they are all backing up the idea. I now felt it was time to take it to this group in order to get a response from a larger group. We all came to the conslusion that by giving the RETR command a second argument specifying the offset of where to start downloading would probably be the best idea. Also, there was a discussion on wheather an octet range, (a third argument, specifying where the end of the download should take place) would be appropriate now that we see a lot more portable internet devices where bandwidth is scarce. A breakdown on savings: 1) Less consumption of bandwidth 2) Less resources used on the servers 3) ISPs wishing to have this feature will not be forced to deploy an IMAP server Not to mention happier users getting their files faster and cheaper (in Sweden, and most other countries in Europe, flatrates are just a mere dream). // Anders Rundegren