[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Extended RETR - version 2
I'm attaching the revised version of the draft (I haven't uploaded it to
IETF since I thought you might have more comments, which I hope). I've
done some changes based on your feedback and the one thing that struck
me was Alexey's comment below:
> BTW, ESMTP Checkpoint/Restart extension (RFC 1845) that does exactly the
> same thing for SMTP (and suffers from the same dot stuffing problem)
> says:
>
> Any octets added by any SMTP data-stuffing algorithm do
> not count as part of this offset. In the case of data transferred
> with the DATA command the offset must also correspond to the
> beginning of a line.
This is a very good point. I've added a section explaining bytestuffing,
in which I also added a sentence that clarifies that offsets are
calculated "unstuffed".
// Anders
INTERNET-DRAFT INTERNET-DRAFT
A. Rundegren
17 February, 2000
Extended RETR - Extension to POP3
<draft-rundegren-pop3-01.txt>
Status of this Memo
This document is an Internet-Draft and is in full
conformance with all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet
Engineering Task Force (IETF), its areas, and its working
groups. Note that other groups may also distribute working
documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of
six months and may be updated, replaced, or obsoleted by
other documents at any time. It is inappropriate to use
Internet-Drafts as reference material or to cite them other
than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be
accessed at http://www.ietf.org/shadow.html.
Distribution of this document is unlimited. Please send
comments to the author.
Abstract
This memo introduces an extension to the RETR command in the
POP3 protocol. The extension makes it possible for an
interrupted RETR command to be continued. This is
particularly useful when downloading large messages over
unstable connections.
A. Rundegren [page 1]
-- LINE -- 58 --
INTERNET-DRAFT 17 February, 2000
Table of Contents
1. Introduction ........................................... 2
2. The Extended RETR Command .............................. 2
2.1 RFC 1939 Specification .............................. 2
2.2 The Offset Argument ................................. 3
2.3 Bytestuffing ........................................ 4
3. Extended Response Codes ................................ 4
4. The CAPA Tag ........................................... 5
5. Security Considerations ................................ 6
6. Acknowledgements ....................................... 6
7. References ............................................. 6
8. Author's Address ....................................... 6
1. Introduction
When email was first developed it was intended to transfer
readable text messages. Since the introduction of MIME (RFC
2045) it has become more common to transfer other message
parts, more commonly known as attachments. These attachments
are often much larger than the readable textparts.
Many clients connecting to an ISP, or even the ISP itself,
have their modems setup in a way that doesn't handle a noisy
phoneline very well. When line-quality isn't high enough, this
often results in a premature disconnect.
Using commands currently found in the the POP3 protocol, 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.
By extending the RETR command, the download-and-delete model
that characterizes the POP3 protocol becomes more complete in
handling todays requirements of email. Consider the benefits:
a) Less resources used on the server-side
b) Less time used online for the client
c) Less consumption of bandwidth
2. The Extended RETR Command
This section will give a detailed view on how the second
argument of the extended RETR command should be implemented.
2.1 RFC 1939 Specification
The RETR command (as specified by RFC 1939), takes one argument
which specifies the message to be retrieved by the client. The
possible responses are "+OK" and "-ERR", without the quotes.
A. Rundegren [page 2]
-- LINE -- 116 --
INTERNET-DRAFT 17 February, 2000
2.2 The Offset Argument
The second argument to the extended RETR command specifies the
offset in the message of where the transfer should start. The
offset is given in octets. All data that is transferred with a
standard RETR command should be accounted for. This means that
top headers, followed by messageparts will be transferred, in
that order. As specified by RFC 1939, responses can not be more
than 512 characters long, including the terminating CRLF.
The syntax of the extended RETR command would be:
RETR msg offset
Arguments:
A message-number (required) which may NOT refer to a
message marked as deleted. An offset (optional) of where
to start the transfer, specified in octets. If the offset
argument is omitted, the message will be sent as specified
by the RETR command in RFC 1939.
Description:
If the POP3 server issues a positive response, then the
response given is multi-line. After the intial +OK, the
POP3 server sends the message corresponding to the given
message-number, starting from the offset provided, being
careful to byte-stuff the termination character (as with
all multi-line responses).
Possible Responses:
+OK message follows
-ERR no such message
Examples:
C: RETR 1 345628
S: +OK 1253512 octets
S: <the POP3 server sends the message here, starting with
the 345628th octet of the message>
S: .
If the specified offset is beyond the size of the message being
retrieved, or in any other way erroneous in its syntax, the
server should respond with a negative response code. This would
however not distinguish the type of error. In the following
section you can read about the use of extended response codes
to clarify errormessages.
A. Rundegren [page 3]
-- LINE -- 174 --
INTERNET-DRAFT 17 February, 2000
2.3 Bytestuffing
This section explains how bytestuffing should be performed when
resuming a previously interrupted transfer. When data is to be
transferred from the server to the client, the server should
be careful to byte-stuff all data. If the previous transfer
was interrupted in the middle of a line, where the remaining
part of the line starts with a '.' character, this means that
data, that would normally not be bytestuffed (since it's not in
the beginning of a line), must be byte-stuffed. Any octets added
by any data-stuffing algorithm do not count as part of the offset
used by the Extended RETR command.
Examples:
Message number is 1.
Message size is 217,743 octets.
Offset 113,435 starts with a '.'.
Lets assume, that when transferring the above message, an
interrupt occurs after exactly 113,435 octets. When
resuming the transfer, the client executes "RETR 1 113435".
The server then byte-stuffs the data before transferring it
to the client, who then byte-destuffs the data before
appending it to the previously transferred data.
3. Extended Response Codes
The extended RETR command does not require the implementation
of extended response codes (RFC 2449) to be present in order
to work. However, this memo specifies the extended response
codes to be used if implemented.
If the specified offset is beyond the size of the message being
retrieved, the extended response code should be:
-ERR [OFFSET-OVERRUN] message exists
If an error occured because the message was not present on the
server, the extended response code should be:
-ERR [NON-EXISTENT] no such message
For all other type of errors, a simple "-ERR" is sufficient.
A. Rundegren [page 4]
-- LINE -- 232 --
INTERNET-DRAFT 17 February, 2000
4. The CAPA Tag
The extended RETR command introduces a new CAPA tag (RFC 2449).
This tag tells the client that the server is able to continue
interrupted RETR commands. Its implementation is mandatory.
CAPA tag:
EXT-RETR
Arguments:
none
Added commands:
n/a
Standard commands affected:
RETR
Announced states / possible differences:
both / no
Commands valid in states:
TRANSACTION
Specification reference:
[POP3, this document]
Discussion:
The extended RETR capability indicates that the server is
capable of excepting a second argument to the RETR command
in order to resume a previously interrupted RETR command.
A. Rundegren [page 5]
-- LINE -- 290 --
INTERNET-DRAFT 17 February, 2000
5. Security Considerations
Use of the extended RETR command sends messages in the clear
over the network.
6. Acknowledgements
The extension introduced in this memo is based on the RETR
command as specified in RFC 1939. I would like to thank
R. Gellens, C. Newman and L. Lundblade for their comments
and suggestions during the drafting of this document.
7. References
1) Post Office Protocol - Version 3 (RFC 1939).
J. Myers, M. Rose.
2) Multipurpose Internet Mail Extensions, Part One (RFC 2045).
N. Freed, N. Borenstein.
3) POP3 Extension Mechanism (RFC 2449).
R. Gellens, C. Newman, L. Lundblade.
8. Author's Address
Anders Rundegren
Skimmelgatan 1
212 35 Malmo
Sweden
email: anders@xxxxxxxxxxxxx
A. Rundegren [page 6]
-- LINE -- 348 --