Re: Extended RETR - Draft posted

> 
> > Yes, it seems we need that.  There's one more issue that you'd need
> > to decide on -- are we calculating CRLF's the way they're transferred
> > over POP3 (would be more essential for the protocol), or the way line
> > separators are typically stored on a UNIX-based server (to allow for
> > a simple seek).
> 
> There are servers that 
> 1). construct message on the flight, storing it in some different
> format.
> 2). store headers separately from body.
> 3). store message with CRLF even if they run on Unix
> 4). store message in bytestuffed form (as received from SMTP)
> 
> Whatever rule you choose for calculation of offset you will not satisfy
> ALL implementations, 

Yes, indeed.

> so there is no point doing that.

Not necessarily: it might make sense to make life easier for those
servers for which it would be harder to switch to a more efficient
(for our POP3 extension) mailbox format.

I agree that this is probably not worth the extra complexity this
would bring into the specification of such a POP3 extension.

> 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.
> 
> In checkpoint/restart offset starts from 0.
> I would suggest to use the same for consistency.

> Would it be easier to use TOP-like command? Something like
> 
>    TOP <msgnum> <lines> <start_from_line>

TOP would be more consistent with current POP3, as we already have
line number arguments, but don't have octet ones, yet.

However, as you have pointed out, it would be inconsistent with the
SMTP extension.

Signed,
Solar Designer