INTERNET-DRAFT INTERNET-DRAFT A. Rundegren 27 January, 2000 Extended RETR - Extension to POP3 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] INTERNET-DRAFT 27 January, 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 3. Extended Response Codes ................................ 4 4. The CAPA Tag ........................................... 4 5. Security Considerations ................................ 5 6. Acknowledgements ....................................... 5 7. References ............................................. 5 8. Author's Address ....................................... 5 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 improperly setup which causes an unstable connection, often resulting 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, without the need to deploy IMAP. Consider the benefits: a) Less consumption of bandwidth b) Less resources used on the server-side c) Less time used online for the client 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] INTERNET-DRAFT 27 January, 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. Everything 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, an offset of 0 octects is assumed. 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: S: . If the specified offset is beyond the size of the message being retrieved, or in any other way erroneous in its syntax, the response from the server should start with "-ERR". 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] INTERNET-DRAFT 27 January, 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 message exists [OFFSET-OVERRUN] If an error occured because the message was not present on the server, the extended response code should be: -ERR no such message [NON-EXISTENT] 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. 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 4] INTERNET-DRAFT 27 January, 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@rundegren.com A. Rundegren [page 5]