Re: 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

Below are my proposed changes to the draft.  If the reasoning behind
some is non-obvious, just ask. :-)

--- extended-retr-draft-v2.txt	Sat Feb 19 08:05:15 2000
+++ extended-retr-draft-v2s.txt	Sat Feb 19 10:25:29 2000
@@ -81,23 +81,19 @@
         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.
+        Currently, POP3 requires messages to be re-downloaded from
+        scratch should there be a premature disconnect during a
+        message transfer. Such disconnects happen 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. Consider the benefits:
+        handling todays requirements of email. The benefits are:
 
-        a) Less resources used on the server-side
-        b) Less time used online for the client
-        c) Less consumption of bandwidth
+        a) Less time used online for the client
+        b) Less consumption of bandwidth
+        c) Less resources used on the server side
 
 
 2. The Extended RETR Command
@@ -109,7 +105,8 @@
 
         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.
+        allowed responses are "+OK" and "-ERR", without the quotes,
+        possibly followed by a space and a comment.
 
 
 A. Rundegren                                                    [page 2]
@@ -121,11 +118,14 @@
 
         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.
+        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 (and never a single LF), the offset MUST NOT
+        point into the middle of a CRLF pair.
+
+        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:
 
@@ -140,7 +140,7 @@
 
         Description:
             If the POP3 server issues a positive response, then the
-            response given is multi-line. After the intial +OK, 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
@@ -154,15 +154,24 @@
             C: RETR 1 345628
             S: +OK 1253512 octets
             S: <the POP3 server sends the message here, starting with
-                the 345628th octet of the message>
+                the 345629th octet of the message>
+            S: .
+               ...
+            C: RETR 1 1599140
+            S: +OK 0 octets
             S: .
 
+        Offsets equal to the message size are allowed, as shown in the
+        last example. This can be used by a client to check if it has
+        a complete message and continue the transfer if not, with one
+        command.
+
         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.
+        retrieved, points into the middle of a CRLF pair, or is in any
+        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 error messages.
 
 
 
@@ -209,10 +218,10 @@
         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:
+        If the specified offset is in any way erroneous, the extended
+        response code should be:
 
-            -ERR [OFFSET-OVERRUN] message exists
+            -ERR [INVALID-OFFSET] message exists
 
         If an error occured because the message was not present on the
         server, the extended response code should be:
@@ -237,13 +246,15 @@
 
         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.
+        interrupted RETR commands. Its implementation is mandatory if
+        the server supports this extension and the CAPA command.
 
         CAPA tag:
             EXT-RETR
 
         Arguments:
-            none
+            one of ALWAYS, YES or NO in TRANSACTION state, an optional
+            ALWAYS specifier in AUTHORIZATION state
 
         Added commands:
             n/a
@@ -252,7 +263,7 @@
             RETR
 
         Announced states / possible differences:
-            both / no
+            both / yes
 
         Commands valid in states:
             TRANSACTION
@@ -262,9 +273,21 @@
 
         Discussion:
             The extended RETR capability indicates that the server is
-            capable of excepting a second argument to the RETR command
+            capable of accepting a second argument to the RETR command
             in order to resume a previously interrupted RETR command.
 
+            If a server supports this extension for at least some of
+            the maildrops, it MUST announce the extension while in
+            the AUTHORIZATION state. If the extension is supported
+            for all of the maildrops, the server SHOULD also include
+            the ALWAYS specifier, so that clients don't have to
+            reissue the CAPA command after entering the TRANSACTION
+            state. If announced in the AUTHORIZATION state, the
+            server MUST announce the capability in the TRANSACTION
+            state as well. If the extension is not supported for the
+            particular maildrop, the argument should be set to NO.
+            Otherwise, the argument can be set to either ALWAYS or
+            YES, which should be treated the same by clients.
 
 
 
@@ -293,8 +316,10 @@
 
 5. Security Considerations
 
-        Use of the extended RETR command sends messages in the clear
-        over the network.
+        This extension is believed not to introduce additional
+        security issues. Use of the RETR command sends messages in
+        the clear over the network, unless an encryption layer has
+        been previously negotiated.
 
 
 6. Acknowledgements