Proposed standard for message encapsulation (RFC0934)
Original Publication Date: 1985-Jan-01
Included in the Prior Art Database: 2000-Oct-11
Internet Society Requests For Comment (RFCs)
M.T. Rose: AUTHOR [+1]
STATUS OF THIS MEMO
Network Working Group Marshall T. Rose (Delaware)
Request for Comments: 934 Einar A. Stefferud (NMA)
Proposed Standard for Message Encapsulation
STATUS OF THIS MEMO
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
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
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 ...