1. PRELIMINARIES
Mail in the Internet was not a well-planned enterprise, but instead
arose in more of an "organic" way.
This introductory section is not intended to be a reference model and
concept vocabulary for mail in the Internet. Instead, it only
provides the necessary preliminaries for the concepts and terms that
are essential to this specification.
For the purposes of this specification, mail submission is the
process of putting mail into the mail transfer system (MTS).
For the purposes of this specification, mail delivery is the process
of the MTS putting mail into a user's final mail-box.
Throughout the Internet, presently most of mail submission and
delivery is done through SMTP.
SMTP was defined as a message *transfer* protocol, that is, a means
to route (if needed) and deliver mail by putting finished (complete)
messages in a mail-box. Originally, users connected to servers from
terminals, and all processing occurred on the server. Now, a split-
MUA (Mail User Agent) model is common, with MUA functionality
occurring on both the user's own system and the server.
In the split-MUA model, getting the messages to the user is
accomplished through access to a mail-box on the server through such
protocols as POP and IMAP. In the split-MUA model, user's access to
its message is a "Message Pull" paradigm where the user is required
to poll his mailbox. Proper message delivery based on a "Message
Push" paradigm is presently not supported. The EMSD protocol
addresses this shortcoming with an emphasis on efficiency.
In the split-MUA model, message submission is often accomplished
through SMTP. SMTP is widely used as a message *submission* protocol.
Widespread use of SMTP for submission is a reality, regardless of
whether this is good or bad. EMSD protocol provides an alternative
mechanism for message submission which emphasizes efficiency.
1.2. Relationship Of EMSD To Other Mail Protocols
Various Internet mail protocols facilitate accomplishment of various
functions in mail processing.
Figure 1, categorizes the capabilities of SMTP, IMAP, POP and EMSD
based on the following functions:
+------------------+------+-------+-----+------+
| Protocols| SMTP | IMAP | POP | EMSD |
|Functions | | | | |
|------------------|------|-------|-----|------|
|Submission | XX | | | XXX |
|------------------|------|-------|-----|------|
|Delivery | XXX | | | XXX |
|------------------|------|-------|-----|------|
|Relay (Routing) | XXX | | | |
|------------------|------|-------|-----|------|
|Retrieval | | XXX | XXX | XX |
|------------------|------|-------|-----|------|
|Mailbox Access | | XXX | X | |
|------------------|------|-------|-----|------|
|Mailbox Synch. | | XXX | | |
+------------------+------+-------+-----+------+
Figure 1: Messaging Protocols vs. Supported Functions
o Mail Submission
o Mail Delivery
o Mail Routing (Relay)
o Mail Retrieval
o Mail-box Access
o Mail-box Synchronization
In Figure 1, the number of "X"es in each box denotes the extent to
which a particular function is supported by a particular protocol.
Figure 1 clearly shows that combinations of these protocols can be
used to complement each other in providing rich functionality to the
user. For example, a user interested in highly mobile messaging
functionalities can use EMSD for "submission and delivery of time
critical and important messages" and use IMAP for comprehensive
access to his/her mail-box.
For mail submission and delivery of short messages EMSD is up to 5
times more efficient than SMTP both in terms of the number of packets
transmitted and in terms of number of bytes transmitted. Even with
PIPELINING and other possible optimizations of SMTP, EMSD is up to 3
times more efficient than SMTP both in terms of the number of packets
transmitted and in terms of number of bytes transmitted. Various
efficiency studies comparing EMSD with SMTP, POP and IMAP are
available. See Section C.1.1 for more information about comparison
of SMTP and EMSD's efficiency.
The requirements and goals driving design of EMSD protocol are
enumerated below.
1. Provide for submission of short mail messages with the same level
of functionality (or higher) that the existing Internet mail
protocols provide.
2. Provide for delivery of short mail messages with the same level
of functionality (or higher) that the existing Internet mail
protocols provide.
3. Function as an extension of the existing mainstream Internet
mail.
4. Minimize the number of transmissions.
5. Minimize the number of bytes transmitted.
6. Be quick: minimize latency of message submission and delivery.
7. Provide the same level of reliability (or higher) that the
existing email protocols provide.
8. Accommodate varying sizes of messages: the size of a message may
determine how the system deals with the message, but the system
must accommodate it.
9. Be power efficient and respect mobile platform resources:
including memory and CPU levels, as well as battery power
longevity (i.e. client-light and server-heavy).
10. Highly extendible: different users will demand different
options, so the solution cannot require every feature to be a
part of every message. Likewise, usage will emerge that is not
currently recognized as a requirement. The solution must be
extendible enough to handle new, emerging requirements.
11. Secure: provide the same level of security (or higher) that the
existing email protocols provide. Content confidentiality,
originator/recipient authentication and message integrity must
be available options to users.
12. Easy to implement: Re-use existing technology as much as
possible.
1.4. Anticipated Uses Of EMSD
Any network and network operator which has significant bandwidth and
capacity limitations can benefit from the use of EMSD. Any network
user who must bear high costs for measured network usage can benefit
from the use of EMSD.
Initial uses of EMSD is anticipated to be primarily over IP-based
wireless networks to provide two-way paging services.
EMSD can also function as an adjunct to Mail Access Protocols for
"Mail Notification Services".
Considering:
o that most wireless networks shall converge toward being IP-
based;
o that two-way paging is the main proven application in most
wide-area wireless networks;
o that two-way paging industry and the Internet Email industry can
and should converge based on a set of open protocols that
address the efficiency requirements adequately;
o that existing Internet email protocols are not bandwidth
efficient;
o that existing Internet email protocols do not properly support
the "push" model of delivery of urgent messages,
the EMSD protocol is designed to facilitate the convergence of IP-
based two-way paging and Internet email.
Mail submission and delivery take place at the edges of the network.
More than one mail submission and delivery protocols which address
requirements specific to a particular user's environment are likely
to be developed. Such diversity on the edges of the network is
desirable and with the right protocols, this diversity does not
adversely impact the integrity of the mail transfer system. EMSD is
the initial basis for the mail submission and delivery protocol to be
used when the user's environment demands efficiency.
1.5. Definitions of Terms Used in this Specification
The following informal definitions and acronyms are intended to help
describe EMSD model described in this specification.
Efficient Mail Submission and Delivery Protocol (EMSD-P): The
protocol used to transfer messages between the EMSD - Server
Agent (e.g., a Message Center) and the EMSD - User Agent (e.g., a
Two-Way Pager), see Figure 2.
Message Transfer Agent (MTA)
Message Transfer Service (MTS)
Message Routing Service (MRS): Collection of MTAs responsible for
mail routing.
Message User Agent (MUA)
Efficient Mail Submission Server Agent (EMS-SA): An Application
Process which conforms to this protocol specification and accepts
mail from an EMS-UA and transfers it towards its recipients.
Efficient Mail Delivery Server Agent (EMD-SA): An Application Process
which conforms to this protocol specification and delivers mail
to an EMD-UA.
Efficient Mail Submission and Delivery Server Agent (EMSD-SA): An
Application Process which incorporates both EMS-SA and EMD-SA
capabilities.
Efficient Mail Submission User Agent (EMS-UA): An Application Process
which conforms to this protocol specification and submits mail to
EMS-SA.
Efficient Mail Delivery User Agent (EMD-UA): An Application Process
which conforms to this protocol specification and accepts
delivery of mail from EMD-SA.
Efficient Mail Submission and Delivery User Agent (EMSD-UA): An
Application Process which incorporates both EMS-UA and EMD-UA
capabilities.
1.6. Conventions Used In This Specification
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
in this specification are to be interpreted as defined in [2].
This specification uses the ES-OPERATION notation defined in
Efficient Short Remote Operations (ESRO) protocols as specified in
RFC-2188 [1].
Operations and information objects are typically described using the
ES-OPERATION and ASN.1 notations in the relevant sections of the
specification.
The complete machine verifiable ASN.1 modules are also compiled in
one place in Appendix A and Appendix B.
1.7. About This Specification
This protocol specification constitutes a point-of-record. It
documents information exchanges and behaviors of existing
implementations. It is a basis for implementation of efficient mail
submission and delivery user agents and servers.
This specification has been developed entirely outside of IETF. It
has had the benefit of review by many outside of IETF. Much has been
learned from existing implementations of this protocol. A number of
deficiencies and areas of improvement have been identified and are
documented in this specification.
This protocol specification is being submitted on October 23, 1998
for timely publication as an Informational RFC.
Future development and enhancements to this protocol may take place
inside of IETF.
