Proposed standard for message encapsulation
RFC 934
|
Document |
Type |
|
RFC - Unknown
(January 1985; No errata)
|
|
Authors |
|
|
|
Last updated |
|
2013-03-02
|
|
Stream |
|
Legacy
|
|
Formats |
|
plain text
html
pdf
htmlized
bibtex
|
Stream |
Legacy state
|
|
(None)
|
|
Consensus Boilerplate |
|
Unknown
|
|
RFC Editor Note |
|
(None)
|
IESG |
IESG state |
|
RFC 934 (Unknown)
|
|
Telechat date |
|
|
|
Responsible AD |
|
(None)
|
|
Send notices to |
|
(None)
|
Network Working Group Marshall T. Rose (Delaware)
Request for Comments: 934 Einar A. Stefferud (NMA)
January 1985
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
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
header.)
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,
Rose & Stefferud [Page 1]
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
messages.
NOTE: RFC-822 mistakenly refers to distribution as forwarding
(section 4.2). This memo suggests below, that these two
activities can and should be the same.
In the case of an interest group digest, a bursting capability is
especially useful. Not only does the ability to burst a digest
permit a recipient of the digest to reply to an individual digested
message, but it also allows the recipient to selectively process the
other messages encapsulated in the digest. For example, a single
digest issue usually contains more than one topic. A subscriber may
only be interested in a subset of the topics discussed in a
particular issue. With a bursting capability, the subscriber can
burst the digest, scan the headers, and process those messages which
are of interest. The others can be ignored, if the user so desires.
This memo is motivated by three concerns:
In order to burst a message it is necessary to know how the
component messages were encapsulated in the draft. At present
there is no unambiguous standard for interest group digests. This
memo proposes such a standard for the ARPA-Internet. Although
interest group digests may appear to conform to a pseudo-standard,
there is a serious ambiguity in the implementations which produce
digests. By proposing this standard, the authors hope to solve
this problem by specifically addressing the implementation
ambiguity.
Next, there is much confusion as to how "blind-carbon-copies"
should be handled by UAs. It appears that each agent in the
ARPA-Internet which supports a "bcc:" facility does so
differently. Although this memo does not propose a standard for
the generation of blind-carbon-copies, it introduces a formalism
which views the "bcc:" facility as a special case of the
forwarding activity.
Finally, both forwarding and distribution can be accomplished with
Show full document text