[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Extended RETR - Draft posted

> The draft for the extended RETR command has now been posted. Feedback
> is, as always, very appreciated. I'm not sure about the section dealing
> with extended response codes, it definitely needs some more work. Since
> English is not my native language I ask you to look over this too.
> http://www.ietf.org/internet-drafts/draft-rundegren-pop3-00.txt

The initial impression is that this clearly needs more work, perhaps
resulting in a different approach to define offsets within a message.

"The offset is given in octets. Everything transferred with a standard
RETR command should be accounted for."

I am assuming the "everything" applies to byte-stuffing.  Now, let's
assume a transfer got interrupted right before a dot in the message.
The client requests that the transfer is continued from that offset,
and the operation succeeds.  The server byte-stuffs that dot (as it
is now at the beginning of a line being transferred), and transfers
more of the message to the client.  Unfortunately, the client gets
disconnected once again.  It wants to recover the transfer.

The question: what offset should it request this time?  It could have
stored the amount of data it has received, along with the incomplete
message.  However, that amount is one octet larger than what it would
be if the transfer wasn't interrupted the first time.  Obviously, the
server, according to this definition of the extension, expects to see
offsets into the data that would be "transferred with a standard RETR
command" -- that is, without any previously recovered transfers.

With this definition of the RETR extension, the client would have to
detect if the first character it receives after a transfer continues
is a dot _and_ it is not at the beginning of a _message_ line.  It
should then subtract one from the data size it is calculating, for
the case of having to continue the transfer once again.  This should
be at least documented in the same RFC, but I suggest that we better
avoid this extra complexity somehow.

A more obvious requirement of this definition is that the client
either stores the amount of data it has received for each incomplete
message, or re-calculates that amount once it wants to finish the
transfer.  The former is fine if we only want to recover transfers
while the client process is running, but might require extending
mailbox format for some clients if we want that functionality even
after an OS restart.  The latter puts some code from POP3 servers,
which used to be server-specific, into clients as well.

Finally, speaking of your reasoning for the extension --

"       a) Less consumption of bandwidth
        b) Less resources used on the server-side
        c) Less time used online for the client"

I would consider (c) the most important reason.  Bandwidth isn't that
important here, as POP3 transfers are typically within one ISP, from
a mailbox at the ISP to the ISP's dialup line, which is busy anyway.
(b) is not fully achieved with your definition of the offsets, as the
server has to read the entire message from the mailbox to account for

Solar Designer