Browse Prior Art Database

SMTP Service Extension for Checkpoint/Restart (RFC1845)

IP.com Disclosure Number: IPCOM000004101D
Original Publication Date: 1995-Sep-01
Included in the Prior Art Database: 2000-Sep-13
Document File: 6 page(s) / 14K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

D. Crocker: AUTHOR [+3]

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.

This text was extracted from a ASCII Text document.
This is the abbreviated version, containing approximately 21% of the total text.

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.

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...