Re: Extended RETR - version 3
Anders Rundegren <[email protected]>
| Newsgroups | gmane.ietf.pop3ext |
|---|---|
| Message-ID | <[email protected]> |
I've attached version 3 of the draft describing the extended RETR command. It incorporates some changes, suggested by Solar Designer and Jochen Topf. Some suggested changes hasn't been incorporated, see my reasoning for this below. "Offsets equal to message sizes are allowed" -------------------------------------------- I didn't add this to the draft since I found it redundant. If a message transfer being resumed doesn't end with a '.' on a new line followed by a CRLF pair, the transfer would be considered to be incomplete anyway. There should be no need for the server to "double-check" this. Also, it introduces further complexity to the extension. "CAPA tag re-definition" ------------------------ This re-definition of the CAPA tag introduces furthermore complexity and I fail to see the use of being able to specify the availability of the extension to individual users maildrops. I'm not sure on how to best solve the problem with message numbering not being the same between sessions, for now I've included a note to implementors that the use of UIDL is required to ensure validity of the downloaded message. Please continue with all feedback! I find comments posted on this list to be extremely helpful in "bug-tracking" the specification of the extension. // Anders
extended-retr-draft-v3.txt
(text/plain, 11 KB)
INTERNET-DRAFT INTERNET-DRAFT
A. Rundegren
26 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 26 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 ................................ 5
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.
The current POP3 specification requires messages to
re-downloaded from scratch in the case of a premature
disconnect during a message transfer.
Such disconnects happens for various reasons, including poor
phone line quality, modem setup, network packet loss and
temporary network problems.
By extending the RETR command, the download-and-delete model
that characterizes the POP3 protocol becomes more complete in
handling todays requirements of email. The benefits are:
a) Less time used online for the client
b) Less resources used on the server-side
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
allowed responses are "+OK" and "-ERR", without the quotes,
possible followed by a space (decimal code 032) and a comment.
A. Rundegren [page 2]
-- LINE -- 116 --
INTERNET-DRAFT 26 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, and is calculated the way message
sizes are , as defined in section 11 of RFC 1939. In order to
ensure a valid multi-line response, with all lines terminated
with a CRLF pair, the offset MUST NOT point into the middle of
a CRLF pair.
As specified by RFC 1939, responses can not be more htan 512
characters long, including the terminating CRLF.
Implementors should note that there is no guarantee that
the message numbering stays the same between sessions. In
order to ensure the validity of a downloaded message,
the use of a UIDL command is required.
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 initial +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 345629th octet of the message>
S: .
A. Rundegren [page 3]
-- LINE -- 174 --
INTERNET-DRAFT 26 February, 2000
If the specified offset is beyond the size of the message being
retrieved, points into the middle of a CRLF pair, 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.
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.
A. Rundegren [page 4]
-- LINE -- 232 --
INTERNET-DRAFT 26 February, 2000
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.
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 if
the server supports this extension and the CAPA command.
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 26 February, 2000
5. Security Considerations
This extension is believed not to introduce additional security
issues. Use of the extended RETR command sends messages in the
clear over the network, unless an encryption layer has been
previously negotiated.
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: [email protected]
A. Rundegren [page 6]
-- LINE -- 348 --