Browse Prior Art Database

Proposed standard for message encapsulation (RFC0934) Disclosure Number: IPCOM000004350D
Original Publication Date: 1985-Jan-01
Included in the Prior Art Database: 2000-Oct-11
Document File: 9 page(s) / 21K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

M.T. Rose: AUTHOR [+2]



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

Network Working Group Marshall T. Rose (Delaware)

Request for Comments: 934 Einar A. Stefferud (NMA)

January 1985

Proposed Standard for Message Encapsulation


This RFC suggests a proposed protocol for the ARPA-Internet

community, and requests discussion and suggestions for improvements.

Distribution of this memo is unlimited.

Introduction, Scope, and Motivation

The services that a user agent (UA) can offer are varied. Although

all outgoing mail may be thought of as going through a single posting

slot to connect to the message transport system (MTS), it is possible

to consider a message draft being posted as described by one of the

following four types of postings:

Originate - a new message is composed from scratch, which, to the

knowledge of the UA, is unrelated to any message previously

handled by the user.

Reply - a message is composed as a reply to a message previously

received by the user. In most circumstances, the UA aids the user

in composing the reply by constructing the header portion of the

message draft, using components extracted from the received

message headers.

Forward - one more more messages previously received by the user

are formatted by the UA as a part of the body portion of the

draft. In this sense, a "digest" for an interest group may be

considered as forwarding. Similarly, an argument may be made that

"blind-carbon-copies" should also be handled in this fashion.

Distribute - a message previously received by the user is

re-posted to the MTS. The draft being re-posted is identical to

the original message with the exception that certain "ReSent-XXX"

headers are appended to the headers portion of the draft, and the

"Return-Path" header is reset to reference the re-sender's

address. (See [RFC-821] for a discussion of the Return-Path


Most user agents support the first two of these activities, many

support the first three, and a few support all four.

This memo concerns itself only with the third type, which is message

forwarding. (For a brief treatment of the semantics of message

components with respect to replies, see [RFC-822].) In many ways,

RFC 934 January 1985

Message Encapsulation

forwarding can be thought of as encapsulating one or more messages

inside another. Although this is useful for transfer of past

correspondence to new recipients, without a decapsulation process

(which this memo terms "bursting"), the forwarded messages are of

little use to the recipients because they can not be distributed,

forwarded, replied-to, or otherwise processed as separate individual


NOTE: RFC-822 mistakenly refers to distribution as forwarding

(section 4.2). This memo suggests below, ...