Subject: Re: Survey : What clients/servers support CAPA?
From: Steve Hole <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: POP3 Extensions Mailing List <[email-masked]>
Date: Tue, 28 Dec 1999 10:22:19 -0700
List-Id: <ietf-pop3ext.imc.org>

On Sun, 19 Dec 1999 14:47:51 -0700 Alexey Melnikov 
<[email-masked]> 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:[email-masked]
Phone: 780-424-4922

From: Solar Designer <[email-masked]>
Subject: RFC 2449: clarifications needed
To: [email-masked]
Date: Fri, 24 Dec 1999 15:24:31 +0300 (MSK)
Sender: [email-masked]

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

Date: Mon, 20 Dec 1999 11:32:37 -0700
From: Alexey Melnikov <[email-masked]>
To: POP3 Extensions Mailing List <[email-masked]>
Subject: Re: Survey : What clients/servers support CAPA?
Sender: [email-masked]

UW-2000 will support CAPA according to Mark Crispin

Alexey

Date: Sun, 19 Dec 1999 15:34:38 -0700
From: Alexey Melnikov <[email-masked]>
To: POP3 Extensions Mailing List <[email-masked]>
Subject: Re: Survey : What clients/servers support CAPA?
Sender: [email-masked]

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

Date: Sun, 19 Dec 1999 14:47:51 -0700
From: Alexey Melnikov <[email-masked]>
To: POP3 Extensions Mailing List <[email-masked]>
Subject: Survey : What clients/servers support CAPA?
Sender: [email-masked]

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

Date: Fri, 17 Dec 1999 17:50:34 -0500
From: Tony Hansen <[email-masked]>
Organization: AT&T Laboratories
To: Anders Rundegren <[email-masked]>
CC: [email-masked]
Subject: Re: POP3 "resume download" extension
Sender: [email-masked]

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
	[email-masked]

Date: Fri, 17 Dec 1999 13:50:07 -0800
To: "Bonatti, Chris" <[email-masked]>, Keith Moore <[email-masked]>
From: Laurence Lundblade <[email-masked]>
Subject: Re: POP3 "resume download" extension
Cc: "[email-masked]" <[email-masked]>
Sender: [email-masked]

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

From: Keith Moore <[email-masked]>
To: "Bonatti, Chris" <[email-masked]>
cc: Keith Moore <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: POP3 "resume download" extension 
Date: Fri, 17 Dec 1999 13:08:30 -0500
Sender: [email-masked]

> > > 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

Date: Fri, 17 Dec 1999 11:03:42 -0700
From: Alexey Melnikov <[email-masked]>
To: Laurence Lundblade <[email-masked]>
CC: [email-masked]
Subject: Re: POP3 "resume download" extension
Sender: [email-masked]

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

Date: Fri, 17 Dec 1999 09:59:41 -0800
To: Alexey Melnikov <[email-masked]>, Anders Rundegren <[email-masked]>
From: Laurence Lundblade <[email-masked]>
Subject: Re: POP3 "resume download" extension
Cc: [email-masked]
Sender: [email-masked]

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

Date: Fri, 17 Dec 1999 21:06:28 +0500
From: "Bonatti, Chris" <[email-masked]>
Organization: IECA, Inc.
To: Keith Moore <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Subject: Re: POP3 "resume download" extension
Sender: [email-masked]

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

From: Keith Moore <[email-masked]>
To: "Bonatti, Chris" <[email-masked]>
cc: Keith Moore <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: POP3 "resume download" extension 
Date: Fri, 17 Dec 1999 10:06:22 -0500
Sender: [email-masked]

> 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

Date: Fri, 17 Dec 1999 19:32:26 +0500
From: "Bonatti, Chris" <[email-masked]>
Organization: IECA, Inc.
To: Keith Moore <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Subject: Re: POP3 "resume download" extension
Sender: [email-masked]

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

From: Keith Moore <[email-masked]>
To: "Bonatti, Chris" <[email-masked]>
cc: Keith Moore <[email-masked]>, Anders Rundegren <[email-masked]>, Alexey Melnikov <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: POP3 "resume download" extension 
Date: Fri, 17 Dec 1999 09:10:43 -0500
Sender: [email-masked]

> > 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

Date: Fri, 17 Dec 1999 19:04:32 +0500
From: "Bonatti, Chris" <[email-masked]>
Organization: IECA, Inc.
To: Keith Moore <[email-masked]>, Anders Rundegren <[email-masked]>, Alexey Melnikov <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Subject: Re: POP3 "resume download" extension
Sender: [email-masked]

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  |
 |  [email-masked]   Tel: 301-208-2349   Fax: 301-208-2379  |
 ---------------------------------------------------------------

Date: Fri, 17 Dec 1999 01:15:28 -0700
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: POP3 "resume download" extension
Sender: [email-masked]

> 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

From: Keith Moore <[email-masked]>
To: [email-masked]
cc: Anders Rundegren <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: POP3 "resume download" extension 
Date: Fri, 17 Dec 1999 01:22:26 -0500
Sender: [email-masked]

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 <msgno> <start> <max-length>

(PRET = "partial retrieve")

where <start> 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

Date: Fri, 17 Dec 1999 05:09:14 +0000
From: "R.Srinivasan" <[email-masked]>
Reply-To: [email-masked]
Organization: Ramp Network (p) Ltd
To: Anders Rundegren <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Subject: Re: POP3 "resume download" extension
Sender: [email-masked]

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

Date: Fri, 17 Dec 1999 02:12:39 +0100
From: Anders Rundegren <[email-masked]>
To: Alexey Melnikov <[email-masked]>
CC: [email-masked]
Subject: Re: POP3 "resume download" extension
Sender: [email-masked]

> 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

Date: Thu, 16 Dec 1999 17:03:12 -0700
From: Alexey Melnikov <[email-masked]>
To: Anders Rundegren <[email-masked]>
CC: [email-masked]
Subject: Re: POP3 "resume download" extension
Sender: [email-masked]

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

Date: Fri, 17 Dec 1999 00:23:24 +0100
From: Anders Rundegren <[email-masked]>
To: [email-masked]
Subject: POP3 "resume download" extension
Sender: [email-masked]

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

Date: Fri, 17 Dec 1999 00:23:24 +0100
From: Anders Rundegren <[email-masked]>
To: [email-masked]
Subject: POP3 "resume download" extension
Sender: [email-masked]

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