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