Re: Extended RETR - Draft posted

Solar Designer wrote:

> 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, 
so there is no point doing that.

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.

> > The model should be very simple, please correct me if I'm wrong:
> >
> > msg-offset-bytestuff-server-client-bytedestuff-msg
> 
> Unfortunately, there may be a few more conversions:
> 
> server_mailbox -> skip(*)_to_offset -> bytestuff -> LF_to_CRLF -> ...
> ... transfer -> bytedestuff -> convert_to_client_mailbox_format
> 
> (*) we haven't defined the "skip" for the server_mailbox "layer", yet.
> 
> > Example:
> >
> > Message number is '1'.
> > Message size is 217,743 bytes.
> > Offset 113,435 starts with a '.'.
> >
> > Lets assume our transfer got interrupted after 113,434 bytes. Now, the
> 
> To illustrate the case of having to byte-stuff, you'd want the
> transfer to be interrupted after 113,435 bytes.

Would it be easier to use TOP-like command? Something like

   TOP <msgnum> <lines> <start_from_line>
  
Alexey