Re: [Andrew Rutherford <andrewr@iagu.net>] Re: Resume command for ESMTP?

[ned.freed at mrochek.com]

> However, my comments, is that I had a look at "SMTP Service Extension
> for Checkpoint/Restart" RFC 1845, which is Experimental. My guess is
> that this RFC would need a review and may be moved to the standard
> track...

Why? The specification is there. Nothing prevents you from using an
experimental specification, so if it solves your problem by all means implement
it.

The purpose of having experimental specifications is to gain experience. Unless
there are implementations that demonstate this extension's value there's
effectively no chance of it or anything like it being placed on the standards
track.

> I would like comments on the way I though about it, and the way it is
> presented, what do you think of the 2 methods?

I think there needs to be a compelling reason to change from what's already
specified. And regardless of this, there needs to be substantial implementation
experience and demonstration of worth before moving any scheme to the standards
track.

> in RFC 1845
> The server send CHECKPOINT to the EHLO command, then the client in the
> MAIL FROM adds TRANSID with a transaction ID, which the server answers
> with ok or with a number of byte to resume from.

> In what I envisaged
> The server send RESUME to the EHLO command, then the client before DATA
> send the RESUME command (with or without a session ID) which the server
> answer by a SESSION with a session ID and a number of Bytes to resume
> from (or 0 to start from the beginning again).

> I feel in the last system letting the server give the session ID to the
> client ensure that the session ID is unique on the server, and that the
> client learn about the session ID only if it has tried before to send
> the message.

Generating unique ids is totally trivial for either a client or a server,
so this isn't a valid concern IMO.

				Ned