Subject: rfc 3030 comments...

From: Franck Martin <[email-masked]>
Date: 10 Sep 2001 13:34:20 +0000

I'm just reading the rfc 3030 you made. I have been looking around for
such protocol for large messages and I have been talking about it on the
[email-masked] mailing list.

I think the RFC could be even greater if it would allow to send chunks
in separate sessions... Bigger will be the mail message, higher there
will be a session error or connection drop. Therefore you have to be
able to recover (like http and ftp protocol do)...

An extension to RFC3030 would be to have the server answering by a
session ID with chunking and to use this ID in following BDAT commands
in other sessions to recover from where the system left... Or other
means of recovery... 

So if the session drops, the client issue a SESSION <sessionid> command
where the server answers 250 ok to resume from <offset in bytes to
resume from>

I know there is an experimental RFC out there that propose recovery, but
it would be nicer if it was built in this RFC...

example:

   R: <wait for connection on TCP port
   S: <open connection to server>
   R: 220 cnri.reston.va.us SMTP service ready
   S: EHLO ymir.claremont.edu
   R: 250-cnri.reston.va.us says hello
   R: 250-PIPELINING
   R: 250-BINARYMIME
   R: 250 CHUNKING 345233
   S: MAIL FROM:<[email-masked]> BODY=BINARYMIME
   S: RCPT TO:<[email-masked]>
   S: RCPT TO:<[email-masked]>
   R: 250 <[email-masked]>... Sender and BINARYMIME ok
   R: 250 <[email-masked]>... Recipient ok
   R: 250 <[email-masked]>... Recipient ok
   S: BDAT 100000
   S: (First 10000 octets of canonical MIME message data)

   <connection lost>

   R: <wait for connection on TCP port
   S: <open connection to server>
   R: 220 cnri.reston.va.us SMTP service ready
   S: EHLO ymir.claremont.edu
   R: 250-cnri.reston.va.us says hello
   R: 250-PIPELINING
   R: 250-BINARYMIME
   R: 250 CHUNKING 452334
   S: MAIL FROM:<[email-masked]> BODY=BINARYMIME
   S: RCPT TO:<[email-masked]>
   S: RCPT TO:<[email-masked]>
   R: 250 <[email-masked]>... Sender and BINARYMIME ok
   R: 250 <[email-masked]>... Recipient ok
   R: 250 <[email-masked]>... Recipient ok
   S: SESSION 345233
   R: 250 ok to resume from 90000
   S: BDAT 10324
   S: (Remaining 10324 octets of canonical MIME message data)
   S: BDAT 0 LAST
   R: 250 90000 octets received from previous session
   R: 250 10324 octets received
   R: 250 Message OK, 100324 octets received
   S: QUIT
   R: 221 Goodbye

Cheers
[email-masked]

---

From: [email-masked]
Date: Mon, 10 Sep 2001 12:34:00 -0400

> in other sessions to recover from where the system left... Or other

I've read over RFC1845 (SMTP Checkpoint/Restart), and it *seems* to do
what you want.  However, I'm cc:ing this to the IETF-SMTP list, in case
somebody with more knowledge of RFC3030 and 1845 can see if there's any
subtle interaction.  It *looks* like it should be OK, as per RFC1845
you are handed a '355 octet-offset is the transaction offset' before
you commmit to sending a 'BDAT nnnn' to start sending.

RFC1845 does say this:

   The SMTP canonical format for messages is used when this offset is
   computed.  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.

It's unclear if the beginning-of-line requirement applies if BDAT is
in use, or how it would be handled if binary data was being transmitted.
-- 
				Valdis Kletnieks
				Operating Systems Analyst
				Virginia Tech