SMTP Service Extension for Checkpoint/Restart
RFC 1845
|
Document |
Type |
|
RFC - Experimental
(September 1995; No errata)
|
|
Authors |
|
Dave Crocker
,
Ned Freed
|
|
Last updated |
|
2013-03-02
|
|
Stream |
|
IETF
|
|
Formats |
|
plain text
html
pdf
htmlized
bibtex
|
Stream |
WG state
|
|
(None)
|
|
Document shepherd |
|
No shepherd assigned
|
IESG |
IESG state |
|
RFC 1845 (Experimental)
|
|
Consensus Boilerplate |
|
Unknown
|
|
Telechat date |
|
|
|
Responsible AD |
|
(None)
|
|
Send notices to |
|
(None)
|
Network Working Group D. Crocker
Request For Comments: 1845 Brandenburg Consulting
Category: Experimental N. Freed
Innosoft International, Inc.
A. Cargille, WG Chair
September 1995
SMTP Service Extension
for Checkpoint/Restart
Status of this Memo
This memo defines an Experimental Protocol for the Internet
community. This memo does not specify an Internet standard of any
kind. Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited.
Abstract
This memo defines an extension to the SMTP service whereby an
interrupted SMTP transaction can be restarted at a later time without
having to repeat all of the commands and message content sent prior
to the interruption.
1. Introduction
Although SMTP is widely and robustly deployed, various extensions
have been requested by parts of the Internet community. In
particular, when dealing with very large messages over less reliable
connections it is possible for substantial resources to be consumed
by repeated unsuccessful attempts to transmit the message in its
entirety. The original SMTP specification [1] does not provide any
means to pick up a partially completed transaction after the
underlying TCP connection has been broken and reestablished.
This memo provides a facility by which a client can uniquely identify
a particular SMTP transaction. The server then stores this
identifying information along with all the information it receives as
the transaction proceeds. If the transaction is interrupted during
the data transfer phase the SMTP client may establish a new SMTP
session at a later time and ask the server to continue the
transaction from the point where the server lost its connection with
the client. The server then reestablishes the transaction context and
tells the client where to resume operations. If this is acceptable
the client resumes operations at this point.
Crocker, Freed & Cargille Experimental [Page 1]
RFC 1845 SMTP Checkpoint/Restart September 1995
This extension may also be used to work around the common timeout
problem where a client times out waiting for a response from the
server acknowledging that the message has been accepted. However, use
of this extension is not an acceptable substitute for proper setting
of timeout parameters.
2. Framework for the Checkpointing Extension
The checkpointing extension is laid out as follows:
(1) the name of the SMTP service extension defined here is
checkpointing;
(2) the EHLO keyword value associated with the extension is
CHECKPOINT;
(3) no parameter is used with the CHECKPOINT EHLO keyword;
(4) one optional parameter using the keyword TRANSID is
added to the MAIL FROM command. The value associated
with this parameter, coupled with the name of the
client taken from EHLO command, forms a globally unique
value that identifies this particular transaction and
serves to distinguish it from all others. This value is
case-sensitive. The syntax of the value is as follows,
using the ABNF notation of [2]:
transid-value ::= "<" transid-spec ">"
; transid-value may not be longer than
; 80 characters
transid-spec ::= transid-local "@" transid-domain
transid-domain ::= transid-token
transid-local ::= transid-token
transid-token ::= transid-atom *("." transid-atom)
transid-atom ::= 1*<any (ASCII) CHAR except SPACE,
CTLs, tspecials, or ".">
NOTE: tspecials is defined in [3]. The TRANSID is
likely to be different from the RFC822 message id,
since it must uniquely identify the particular copy of
the message being sent over this SMTP link. However,
the syntax of transid-value is designed so that any
TRANSID is both a legal RFC822 msg-id as well as being
a legal esmtp-value [4].
(5) The maximum length of a MAIL FROM command line is
increased by 88 characters by the possible addition of
the TRANSID keyword and value;
Crocker, Freed & Cargille Experimental [Page 2]
RFC 1845 SMTP Checkpoint/Restart September 1995
(6) no additional SMTP verbs are defined by this extension;
and,
(7) the next section specifies how support for the
extension affects the behavior of a server and client
SMTP.
3. The checkpointing service extension
Show full document text