Re: Extended RETR - Draft posted

Anders Rundegren wrote:
> 
> The draft for the extended RETR command has now been posted. Feedback
> is, as always, very appreciated. I'm not sure about the section dealing
> with extended response codes, it definitely needs some more work. Since
> English is not my native language I ask you to look over this too.
> 
> http://www.ietf.org/internet-drafts/draft-rundegren-pop3-00.txt

Few comments:

1). 1. Introduction:

>Many clients connecting to an ISP, or even ISP itself,
>***have their modems improperly setup*** ...

I am not sure why you want to blame modem configuration for all
problems.
I use to have 19200 dialup connection to my ISP and a very noisy phone
line.
Sometimes connection was dropped every 5 minutes.

2). 2.2 The offset argument

        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".****

I suggest to change the ending to something like the following:
        the server should send negative response code.


3). 3. Extended Response Codes

Change
  -ERR message exists [OFFSET-OVERRUN]
and
  -ERR no such message [NON-EXISTENT]

to 
  -ERR [OFFSET-OVERRUN] message exists
and
  -ERR [NON-EXISTENT] no such message 
respectively

This is according to ABNF in RFC 2449.

I also doubt the usefulness of [NON-EXISTENT] response.
Good behaving client must check the validity of the message number when
it reconnects.
Also if another client deleted the interrupted message while the client
reconnects, the client is risking to resume downloading the next
message. This is not what you expect from the client. In this case some
persistent message Id should be used (UIDL?).

Alexey