EMSD Format Standard (EMSD-FS) is a non-textual form of compact encoding of Internet mail (RFC-822) messages which facilitates efficient transfer of messages. EMSD-FS is used in conjunction with the EMSD-P but is not a general replacement for RFC-822. EMSD-FS defines a method of representation of short interpersonal message. It defines the ``Content'' encoding (Header + Body). Although EMSD-FS contains end-to-end information its scope is purely point-to-point.
The "Efficient InterPersonal Message Format Standard" is defined in this section. This standard is primarily intended for communication among people.
The EMSD Format Standard is designed to be fully consistent with RFC-822 [2]. In many ways EMSD-FS can be considered to be an efficiency oriented encoder and decoder. Through use of EMSD-FS an RFC-822 message is converted to a more compact binary encoding. This more compact message is then transfered between an EMSD-SA and EMSD-UA. The compact message (represented in EMSD-FS) may then be converted back to RFC-822 intact.
For messages that are originated (submitted) with EMSD protocol, certain fields (e.g., addresses, message-id) can have special forms that are specialized and produce more compact EMSD-FS encoding. These special forms are legitimate values of RFC-822 messages.
This specification expresses information objects using ASN.1 [X.208]. Encoding of ASN.1 shall be based on Basic Encoding Rules (BER) [4]. Future revisions of this specification will use Packed Encoding Rules (PER) [3].
The convention of (O) "OPTIONAL", (D) "DEFAULT", (C) "CONDITIONAL" and (M) "MANDATORY" which express requirements for presence of information is used in this section.
An interpersonal message (IPM) consists of a heading and a body.
IPM ::= SEQUENCE
{
heading Heading,
body Body OPTIONAL
};
The fields that may appear in the Heading of an IPM are defined and described below.
Heading ::= SEQUENCE
{
-- Address of the sending agent (person, program, machine) of
-- this message. This field is mandatory if the sender
-- is different than the originator.
sender [0] EMSDORAddress OPTIONAL,
-- Address of the originator of the message
-- (not necessarily the sender)
originator EMSDORAddress,
-- List of recipients and flags associated with each.
recipient-data SEQUENCE SIZE (1..ub-recipients)
OF PerRecipientFields,
-- Flags applying to this entire message
per-message-flags [1] IMPLICIT BIT STRING
{
-- Priority values
-- At most one of "non-urgent" and "urgent" may be specified
-- concurrently. If neither is specified, then a Priority
-- level of "normal" is assumed.
priority-non-urgent (0),
priority-urgent (1),
-- Importance values
-- At most one of "low" and "high" may be specified
-- concurrently. If neither is specified, then an
-- Importance level of "normal" is assumed.
importance-low (2),
importance-high (3),
-- Indication of whether this message has been
automatically forwarded
auto-forwarded (4)
} OPTIONAL,
-- User-specified recipient who is to receive replies
to this message.
reply-to [2] IMPLICIT SEQUENCE SIZE
(1..ub-reply-to)
OF EMSDORAddress OPTIONAL,
-- Identifier of a previous message, for which this message
-- is a reply
replied-to-IPM EMSDMessageId OPTIONAL,
-- Subject of the message.
subject [3] IMPLICIT AsciiPrintableString
(SIZE (0..ub-subject-field))
OPTIONAL,
-- RFC-822 header fields not explicitly provided for in
-- this Heading. For messages incoming from the external
-- world (i.e. in RFC-822 format), the Message-Id: field
-- need not go here, as it is placed in the
-- Envelope's EMSDMessageId (message-id) field.
extensions [4] IMPLICIT SEQUENCE
(SIZE (0..ub-header-extensions))
OF IPMSExtension OPTIONAL,
-- MIME Version (if other than 1.0)
mime-version [5] IMPLICIT AsciiPrintableString
(SIZE (0..ub-mime-version-length))
OPTIONAL,
-- Top-level MIME Content Type
mime-content-type [6] IMPLICIT AsciiPrintableString
(SIZE (0..
ub-mime-content-type-length))
OPTIONAL,
-- MIME Content Id
mime-content-id [7] IMPLICIT AsciiPrintableString
(SIZE (0..
ub-mime-content-id-length))
OPTIONAL,
-- MIME Content Description
mime-content-description [8] IMPLICIT AsciiPrintableString
(SIZE (0..ub-mime-content-
description-length))
OPTIONAL,
-- Top-level MIME Content Type
mime-content-transfer-encoding
[9] IMPLICIT AsciiPrintableString
(SIZE (0..ub-mime-content-
transfer-encoding))
OPTIONAL
};
Some fields have components and thus are composite, rather than indivisible. A field component is called a sub-field.
This field is mandatory if the sender is different from the originator.
The Originator heading field (O) identifies the IPM's originator.
PerRecipientFields ::= SEQUENCE
{
recipient-address EMSDORAddress,
per-recipient-flags BIT STRING
{
-- Recipient Types.
-- At most one of "copy" and "blind-copy" may be
-- specified concurrently for a single recipient. If
-- neither is specified, than the recipient
-- is assumed to be a "primary" recipient.
recipient-type-copy (0),
recipient-type-blind-copy (1),
-- Notification Request Types.
-- Only one of "rn" and "nrn" may be specified
-- concurrently, \\x110011 for a single recipient.
-- "rn" implies "nrn" in addition.
notification-request-rn (2),
notification-request-nrn (3),
notification-request-ipm-return (4),
-- Report Request Types
-- At most one of these should be set for a
-- particular recipient. "delivery" implies "non-delivery"
-- in addition.
report-request-non-delivery (5),
report-request-delivery (6),
-- Originator-to-Recipient request for a reply.
reply-requested (7)
} DEFAULT { report-request-non-delivery }
};
The Primary Recipients heading field identifies the zero or more users who are the "primary recipients" of the IPM. The primary recipients might be those users who are expected to act upon the IPM.
The Copy Recipients heading field identifies the zero or more users who are the "copy recipients" of the IPM. The copy recipients might be those users to whom the IPM is conveyed for information.
This field is set if the recipient is on the Carbon Copy (CC) list.
This field is set if the recipient is on the Blind Carbon Copy (BCC) list.
The Blind Copy Recipients heading field (C) identifies zero or more users who are the intended blind copy recipients of the IPM.
The phrase "copy recipients" above has the same meaning as in "Copy Recipients" from Section 6.2.1 . A blind copy recipient is one whose role as such is disclosed to neither primary nor copy recipients.
In the instance of an IPM intended for a blind copy recipient, this conditional field shall be present and identify that user. Whether it shall also identify the other blind copy recipients is a local matter. In the instance of the IPM intended for a primary or copy recipient, the field shall be absent.
A receipt notification (rn) reports its originator's receipt, or his expected and arranged future receipt, of an IPM.
A non-receipt notification (nrn) reports its originator's failure to receive, to accept, or his delay in receiving, an IPM.
When this field is set, the contents of the message are returned along with the notification.
The report request enables the MTS to acknowledge to the MTS-user one or more outcomes of a previous invocation of the message-submission or probe-submission abstract-operations.
A report is returned only in case of non-delivery.
For the message-submission, report-delivery indicates the delivery or non-delivery of the submitted message to one or more recipients. For the probe-submission, the report- delivery indicates whether or not a message could be delivered if the message were to be submitted.
When set this field indicates that the originator requests that a recipient send a message in reply to the message which carries the request.
The Priority field (default is normal) identifies the priority that the authorizing users attach to the IPM. It may assume any one of the following values: urgent, normal, or non-urgent.
At most one of either "non-urgent" or "urgent" may be specified concurrently. If neither is specified, then a Priority level of "normal" is assumed.
The Importance heading field (default normal) identifies the importance that the authorizing users attach to the IPM. It may assume any one of the following values: low, normal, or high.
At most one of either "low" or "high" may be specified concurrently. If neither is specified, then a Importance level of "normal" is assumed.
The values above are not defined by this specification; they are given meaning by users.
The Auto-forwarded heading field (default is false) indicates whether the IPM is the result of auto-forwarding. It is a Boolean value.
User-specified recipient or recipients who are to receive replies to this message.
The Replied-to IPM heading field (C) identifies the IPM to which the present IPM is a reply. It comprises an IPM identifier.
This conditional field shall be present if, and only if, the IPM is a reply.
Note - In the context of forwarding, care should be taken to distinguish between the forwarding IPM and the forwarded IPM. This field should identify whichever of these two IPMs to which the reply responds.
The Subject heading field (O) identifies the subject of the IPM. It corresponds to the "Subject:" field of RFC-822.
The Extensions heading field [D no extensions (i.e. members)] conveys information accommodated by no other heading field. It comprises a Set of zero or more IPMS extensions, each conveying one such information item.
IPMSExtension ::= SEQUENCE
{
x-header-label AsciiPrintableString,
x-header-value AsciiPrintableString
};
The types of body parts that may appear in the Body of an IPM are structured using the MIME specification.
Body ::= SEQUENCE
{
compression-method [0] IMPLICIT CompressionMethod
OPTIONAL,
-- If compression method is not specified,
-- "no-compression" is implied.
message-body OCTET STRING
-- See MIME for structure of the Body.
-- If a compression method is specified, the entire text containing
-- the Content-Type: element followed by the RFC-822 body are
-- compressed using the specified method, and placed herein.
};
CompressionMethod ::= INTEGER
{
-- Compression Methods numbered 0 to 63 are reserved for
-- assignment within this and associated specifications.
no-compression (0),
lempel-ziv (1)
-- Compression Methods numbered between 64 and 127 may be
-- used on a bilaterally-agreed basis between peers.
} (0..127)