[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

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

        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.


        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

            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.

            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

            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.

            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:


        Added commands:

        Standard commands affected:

        Announced states / possible differences:
            both / no

        Commands valid in states:

        Specification reference:
            [POP3, this document]

            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

        email: anders@xxxxxxxxxxxxx

A. Rundegren                                                    [page 6]
-- LINE -- 348 --