summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc2524.txt
diff options
context:
space:
mode:
authorThomas Voss <mail@thomasvoss.com> 2024-11-27 20:54:24 +0100
committerThomas Voss <mail@thomasvoss.com> 2024-11-27 20:54:24 +0100
commit4bfd864f10b68b71482b35c818559068ef8d5797 (patch)
treee3989f47a7994642eb325063d46e8f08ffa681dc /doc/rfc/rfc2524.txt
parentea76e11061bda059ae9f9ad130a9895cc85607db (diff)
doc: Add RFC documents
Diffstat (limited to 'doc/rfc/rfc2524.txt')
-rw-r--r--doc/rfc/rfc2524.txt4651
1 files changed, 4651 insertions, 0 deletions
diff --git a/doc/rfc/rfc2524.txt b/doc/rfc/rfc2524.txt
new file mode 100644
index 0000000..e7f4f1c
--- /dev/null
+++ b/doc/rfc/rfc2524.txt
@@ -0,0 +1,4651 @@
+
+
+
+
+
+
+Network Working Group M. Banan
+Request for Comments: 2524 Neda Communications, Inc.
+Category: Informational February 1999
+
+
+ Neda's
+ Efficient Mail Submission and Delivery (EMSD)
+ Protocol Specification Version 1.3
+
+Status of this Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (1999). All Rights Reserved.
+
+IESG Note
+
+ The protocol specified in this document may be satisfactory for
+ limited use in private wireless IP networks. However, it is
+ unsuitable for general-purpose message transfer or for transfer of
+ messages over the public Internet, because of limitations that
+ include the following:
+
+ - Lack of congestion control
+
+ EMSD is layered on ESRO [RFC 2188], which does not provide
+ congestion control. This makes EMSD completely unsuitable for
+ end-to-end use across the public Internet. EMSD should be
+ considered for use in a wireless network only if all EMSD email
+ exchanged between the wireless network and the public Internet
+ will transit an EMSD<->SMTP gateway between the two regions.
+
+ - Inadequate security
+
+ The document specifies only clear-text passwords for
+ authentication. EMSD should be used across a wireless network
+ only if sufficiently strong encryption is in use to protect the
+ clear-text password.
+
+ - Lack of character set internationalization
+
+ EMSD has no provision for representation of characters outside of
+ the ASCII repertoire or for language tags.
+
+
+
+
+Banan Informational [Page 1]
+
+RFC 2524 EMSD February 1999
+
+
+ - Poorly defined gatewaying to and from Internet Mail
+
+ Because Internet Mail and EMSD have somewhat different and
+ conflicting service models and different data models, mapping
+ between them may provide good service only in limited cases, and
+ this may cause operational problems.
+
+ The IESG therefore recommends that EMSD deployment be limited to
+ narrow circumstances, i.e., only to communicate with devices that
+ have inherent limitations on the length and format of a message (no
+ more than a few hundred bytes of ASCII text), using either:
+
+ a. wireless links with adequate link-layer encryption and gatewayed
+ to the public Internet, or
+
+ b. a private IP network that is either very over-provisioned or has
+ some means of congestion control.
+
+ In the near future, the IESG may charter a working group to define an
+ Internet standards-track protocol for efficient transmission of
+ electronic mail messages, which will be highly compatible with
+ existing Internet mail protocols, and which wil be suitable for
+ operation over the global Internet, including both wireless and wired
+ links.
+
+ABSTRACT
+
+ This document specifies the protocol and format encodings for
+ Efficient Mail Submission and Delivery (EMSD). EMSD is a messaging
+ protocol that is highly optimized for submission and delivery of
+ short Internet mail messages. EMSD is designed to be a companion to
+ existing Internet mail protocols.
+
+ This specification narrowly focuses on submission and delivery of
+ short mail messages with a clear emphasis on efficiency. EMSD is
+ designed specifically with wireless network (e.g., CDPD, Wireless-IP,
+ Mobile-IP) usage in mind. EMSD is designed to be a natural
+ enhancement to the mainstream of Internet mail protocols when
+ efficiency in mail submission and mail delivery are important. As
+ such, EMSD is anticipated to become an initial basis for convergence
+ of Internet Mail and IP-based Two-Way Paging.
+
+ The reliability requirement for message submission and message
+ delivery in EMSD are the same as existing email protocols. EMSD
+ protocol accomplishes reliable connectionless mail submission and
+ delivery services on top of Efficient Short Remote Operations (ESRO)
+ protocols as specified in RFC-2188 [1].
+
+
+
+
+Banan Informational [Page 2]
+
+RFC 2524 EMSD February 1999
+
+
+ Most existing Internet mail protocols are not efficient. Most
+ existing Internet mail protocols are designed with simplicity and
+ continuity with SMTP traditions as two primary requirements. EMSD is
+ designed with efficiency as a primary requirement.
+
+ The early use of EMSD in the wireless environment is manifested as
+ IP-based Two-Way Paging services. The efficiency of this protocol
+ also presents significant benefits for large centrally operated
+ Internet mail service providers.
+
+Table of Contents
+
+ 1 PRELIMINARIES 4
+ 1.1 Internet Mail Submission and Delivery . . . . 4
+ 1.2 Relationship Of EMSD To Other Mail Protocols . . . 5
+ 1.3 EMSD Requirements and Goals . . . . . . . 7
+ 1.4 Anticipated Uses Of EMSD . . . . . . . . 8
+ 1.5 Definitions of Terms Used in this Specification . . 9
+ 1.6 Conventions Used In This Specification . . . . 9
+ 1.7 About This Specification . . . . . . . . 10
+ 2 EFFICIENT MAIL SUBMISSION AND DELIVERY OVERVIEW 10
+ 3 EFFICIENT MAIL SUBMISSION AND DELIVERY PROTOCOL 11
+ 3.1 Use Of Lower Layers . . . . . . . . . 13
+ 3.1.1 Use of ESROS . . . . . . . . . 13
+ 3.1.2 Use Of UDP . . . . . . . . . . 13
+ 3.1.3 Encoding Rules . . . . . . . . . 13
+ 3.1.4 Presentation Context . . . . . . . 14
+ 3.2 EMSD-UA Invoked Operations . . . . . . . 14
+ 3.2.1 submit . . . . . . . . . . . 14
+ 3.2.2 deliveryControl . . . . . . . . 17
+ 3.2.3 deliveryVerify . . . . . . . . . 21
+ 3.3 EMSD-SA Invoked Operations . . . . . . . 23
+ 3.3.1 deliver . . . . . . . . . . 23
+ 3.3.2 submissionControl . . . . . . . . 25
+ 3.3.3 submissionVerify . . . . . . . . 28
+ 3.4 EMSD Common Information Objects . . . . . . 30
+ 3.4.1 SecurityElements . . . . . . . . 30
+ 3.4.2 Message Segmentation and Reassembly . . . 30
+ 3.4.3 Common Errors . . . . . . . . . 33
+ 3.4.4 ContentType . . . . . . . . . 35
+ 3.4.5 EMSDMessageId . . . . . . . . . 35
+ 3.4.6 EMSDORAddress . . . . . . . . . 36
+ 3.4.7 EMSDAddress . . . . . . . . . 36
+ 3.4.8 DateTime . . . . . . . . . . 36
+ 3.4.9 AsciiPrintableString . . . . . . . 37
+ 3.4.10 ProtocolVersionNumber . . . . . . . 37
+ 3.5 Submission and Delivery Procedures . . . . . 38
+ 4 DUPLICATE OPERATION DETECTION SUPPORT 40
+
+
+
+Banan Informational [Page 3]
+
+RFC 2524 EMSD February 1999
+
+
+ 4.1 Duplicate Operation Detection Support Overview . . 40
+ 4.1.1 Operation Value . . . . . . . . 40
+ 4.1.2 Operation Instance Identifier . . . . . 41
+ 5 EMSD PROCEDURE FOR OPERATIONS 42
+ 5.1 MTS Behavior . . . . . . . . . . . 43
+ 5.1.1 MTS Performer . . . . . . . . . 43
+ 5.1.2 Message-submission . . . . . . . . 44
+ 5.1.3 Delivery-control . . . . . . . . 46
+ 5.1.4 Delivery-verify . . . . . . . . 46
+ 5.1.5 MTS Invoker . . . . . . . . . 46
+ 5.2 UA Behavior . . . . . . . . . . . 49
+ 5.2.1 UA Performer . . . . . . . . . 49
+ 5.2.2 UA Invoker . . . . . . . . . . 52
+ 6 EMSD FORMAT STANDARDS 54
+ 6.1 Format Standard Overview . . . . . . . . 54
+ 6.2 Interpersonal Messages . . . . . . . . 54
+ 6.2.1 Heading fields . . . . . . . . . 55
+ 6.2.2 Body part types . . . . . . . . 61
+ 7 ACKNOWLEDGMENTS 62
+ 8 SECURITY CONSIDERATIONS 62
+ 9 AUTHOR'S ADDRESS 62
+ A EMSD-P ASN.1 MODULE 63
+ B EMSD-IPM ASN.1 MODULE 74
+ C RATIONALE FOR KEY DESIGN DECISIONS 78
+ C.1 Deviation From The SMTP Model . . . . . . 78
+ C.1.1 Comparison of SMTP and EMSD Efficiency . . . 78
+ C.2 Use of ESRO Instead of TCP . . . . . . . 79
+ C.3 Use Of Remote Procedure Call (RPC) Model . . . . 79
+ C.4 Use Of ASN.1 . . . . . . . . . . . 80
+ D FURTHER DEVELOPMENT 81
+ E REFERENCES 82
+ F FULL COPYRIGHT STATEMENT 83
+
+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.
+
+1.1 Internet Mail Submission and Delivery
+
+ For the purposes of this specification, mail submission is the
+ process of putting mail into the mail transfer system (MTS).
+
+
+
+
+Banan Informational [Page 4]
+
+RFC 2524 EMSD February 1999
+
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Banan Informational [Page 5]
+
+RFC 2524 EMSD February 1999
+
+
+ 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
+
+
+
+Banan Informational [Page 6]
+
+RFC 2524 EMSD February 1999
+
+
+ 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.
+
+1.3 EMSD Requirements and Goals
+
+ 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.
+
+
+
+
+
+
+Banan Informational [Page 7]
+
+RFC 2524 EMSD February 1999
+
+
+ 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
+
+
+
+
+
+Banan Informational [Page 8]
+
+RFC 2524 EMSD February 1999
+
+
+ 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].
+
+
+
+Banan Informational [Page 9]
+
+RFC 2524 EMSD February 1999
+
+
+ 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.
+
+2 EFFICIENT MAIL SUBMISSION AND DELIVERY OVERVIEW
+
+ This section offers a high level view of the Efficient Mail
+ Submission and Delivery Protocol and Format Standards (EMSD-P&FS).
+
+ The EMSD-P&FS are 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.
+
+ This specification defines the protocols between an EMSD - User Agent
+ (EMSD-UA) and an EMSD - Server Agent (EMSD-SA). The EMSD - P&FS
+ consist of two independent components:
+
+ 1. EMSD Format Standard (EMSD-FS).
+
+ 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
+
+
+
+Banan Informational [Page 10]
+
+RFC 2524 EMSD February 1999
+
+
+ not a general replacement for RFC-822. EMSD-FS defines a method
+ of representation of short interpersonal messages. It defines
+ the "Content" encoding (Header + Body). Although EMSD-FS
+ contains end-to-end information its scope is purely point-to-
+ point. EMSD-FS relies on EMSD-P (see 2 below) for the transfer
+ of the content to its recipients.
+
+ This is described in the section entitled EMSD Format Standards.
+
+ 2. Efficient Mail Submission and Delivery Protocol (EMSD-P).
+
+ EMSD-P is responsible for wrapping an EMSD-FS message (see 1
+ above) in a point-to-point envelope and submitting or delivering
+ it. EMSD-P relies on the services of Efficient Short Remote
+ Operation Services (ESROS) as specified in RFC-2188 [1] for
+ transporting the point-to-point envelope. Some of the services
+ of EMSD-P include: message originator authentication and
+ optional message segmentation and reassembly. The EMSD-P is
+ expressed in terms of abstract services using the ESROS notation.
+ This is described in the section entitled Efficient Mail
+ Submission and Delivery Protocol.
+
+ It is important to recognize that EMSD-P and EMSD-FS are not end-to-
+ end, but focus on the point-to-point transfer of messages. The two
+ points being EMSD-SA and EMSD-UA. EMSD-P function as elements of the
+ Internet mail environment, which provide end-to-end (EMSD-User to any
+ other Messaging Originator or Recipient) services.
+
+ Figure 2 illustrates how the EMSD-P&FS defines the communication
+ between a specific EMSD-UA and a specific EMSD-SA. The Message
+ Transfer System may include a number of EMSD-SAs. Each EMSD-SA may
+ have any number of EMSD-UAs with which it communicates.
+
+ The Efficient Mail Submission and Delivery Services use the Efficient
+ Short Remote Operation Services (ESROS). They also use the Duplicate
+ Operation Detection Support Functions as described in the section
+ entitled Duplicate Operation Detection Support Functions. These
+ functions guarantee that an operation is performed no more than once.
+
+3 EFFICIENT MAIL SUBMISSION AND DELIVERY PROTOCOL
+
+ EM Submission is the process of transferring a message from EMSD-UA
+ to EMSD-SA. EM Delivery is the process of transferring a message from
+ EMSD-SA to EMSD-UA.
+
+
+
+
+
+
+
+Banan Informational [Page 11]
+
+RFC 2524 EMSD February 1999
+
+
+ The Message-submission service enables an EMSD-UA to submit a message
+ to the EMSD-SA for transfer and delivery to one or more recipients.
+ The Message-submission Service comprises of the submit operation --
+ invoked by the EMSD-UA -- and possibly the submitVerify operation --
+ invoked by the EMSD-SA.
+
+ The Message-delivery service enables the EMSD-SA to deliver a message
+ to an EMSD-UA. The Message-delivery Service comprises of the deliver
+ operation -- invoked by the EMSD-SA -- and possibly the deliverVerify
+ operation -- invoked by the EMSD-UA.
+
+ EMSD-UA uses the following services:
+
+ o Message-submission
+
+ +---------------------------------------------+
+ | MTS |
+ | |
+ | +-------------------------+ |
+ | | MRS | |
+ | | +---+ +---+ | |
+ | | | | | M | | +---+ |
+ | | | |<-------->| T |<----------->| | |
+ | | | | | A | | | | | +---+
+ | | | | +---+ | | E | | | E |
+ | | | | | | M | | | M |
+ | | | M | | | S | | EMSD-P&FS | S |
+ | | | T |<-------------------------->| D |<---------------->| D |
+ | | | A | | | - | | | - |
+ | | | | +---+ | | S | | | U |
+ | | | | | M | | | A | | | A |
+ | | | |<-------->| T |<----------->| | | +---+
+ | | | | | A | | | | |
+ | | +---+ +---+ | +---+ |
+ | | | |
+ | +-------------------------+ |
+ | |
+ | |
+ +---------------------------------------------+
+
+
+ Figure 2: Efficient Mail Submission and Delivery Protocol
+
+ o Delivery-control (the deliveryControl operation).
+
+ EMSD-SA uses the following services:
+
+ o Message-delivery
+
+
+
+Banan Informational [Page 12]
+
+RFC 2524 EMSD February 1999
+
+
+ o Submission-control (the submissionControl operation).
+
+ This specification expresses information objects using ASN.1 [X.208].
+
+ This specification expresses Remote Operations based on the model of
+ ESROS as specified in Efficient Short Remote Operations (RFC-2188)
+ [1]. The ES-OPERATION notation of (RFC-2188) is used throughout this
+ specification to define specific operations.
+
+ This specification uses the Duplicate Operation Detection Support
+ functions as specified in Section 4.
+
+3.1 Use Of Lower Layers
+
+3.1.1 Use of ESROS
+
+ ESRO protocol, as specified in (RFC-2188 [1]), provides reliable
+ connectionless remote operation services on top of UDP [6] with
+ minimum overhead. ESRO protocol supports segmentation and
+ reassembly, concatenation and separation.
+
+ ESRO Services (2-Way and 3-Way handshake) shall be used by the EMSD-
+ P.
+
+ ESRO Service Access Point (SAP) selectors used by EMSD-P are
+ enumerated in the protocol.
+
+3.1.2 Use Of UDP
+
+ EMSD-P through ESRO MUST use UDP [6] port number 642 (esro-emsdp).
+
+ Note that specification of Service Access Points (SAP) for EMSD-P
+ include the UDP Port Number specification in addition to ESRO SAP
+ selector specifications. In other words, EMSD-P's use of ESRO SAPs
+ does not preclude use of the same SAP selectors by other protocols
+ which use a UDP port other than port 642. Such usage of ESRO is a
+ design characteristic of ESRO which results into bandwidth efficiency
+ and is not a scalability limitation.
+
+3.1.3 Encoding Rules
+
+ Use of Basic Encoding Rules (BER) [5] is mandatory for both EMSD
+ Format Standards and EMSD Protocol.
+
+ In order to minimize data transfer, the following restrictions shall
+ be maintained in the formatting of EMSD PDUs:
+
+ o Specifically, when ASN.1 Basic Encoding Rules are being used:
+
+
+
+Banan Informational [Page 13]
+
+RFC 2524 EMSD February 1999
+
+
+ A. Only the "Definite" form of Length encoding MUST be used,
+
+ B. The "Short" form of Length encoding MUST be used whenever
+ possible (i.e. when the Length is less than 128), and
+
+ C. OCTET STRING and BIT STRING values, and any other native
+ ASN.1 types which may be encoded as either "Primitive" or
+ "Constructed", MUST always be encoded as "Primitive" and
+ MUST never be "Constructed".
+
+3.1.4 Presentation Context
+
+ Parameter Encoding Type of "0" MUST be used in ESRO Protocol to
+ identify Basic Encoding Rules for operation arguments.
+
+3.2 EMSD-UA Invoked Operations
+
+ The following operations are invoked by EMSD-UA:
+
+ a. submit
+
+ b. deliveryControl
+
+ c. deliveryVerify
+
+ The submit operation uses the duplication detection functional unit
+ while deliveryControl and deliveryVerify don't use the duplication
+ detection.
+
+ The complete definition of these operations follows.
+
+3.2.1 submit
+
+ The submit ES-OPERATION enables an EMSD-UA to submit a message to the
+ EMSD-SA for transfer and delivery to one or more recipients.
+
+ submit ES-OPERATION
+
+ ARGUMENT SubmitArgument
+ RESULT SubmitResult
+ ERRORS
+ {
+ submissionControlViolated,
+ securityError,
+ resourceError,
+ protocolViolation,
+ messageError
+ } ::= 33;
+
+
+
+Banan Informational [Page 14]
+
+RFC 2524 EMSD February 1999
+
+
+ Duplicate operation detection is necessary for this operation.
+
+ The successful completion of the ES-OPERATION signifies that the
+ EMSD-SA has accepted responsibility for the message (but not that it
+ has delivered it to its intended recipients).
+
+ The disruption of the ES-OPERATION by an error signifies that the
+ EMSD-SA cannot assume responsibility for the message.
+
+
+ Arguments
+
+ This operation's arguments are:
+
+ SubmitArgument ::= SEQUENCE
+ {
+ -- Security features
+ security [0] IMPLICIT SecurityElement OPTIONAL,
+
+ -- Segmentation features for efficient transport
+ segment-info SegmentInfo OPTIONAL,
+
+ -- Content type of the message
+ content-type ContentType,
+
+ --
+ -- THE CONTENT --
+ --
+
+ -- The submission content
+ content ANY DEFINED BY content-type
+ };
+
+
+ The fields are:
+
+
+ Security
+
+ See Section 3.4.1, "SecurityElements".
+
+
+ Segment-info
+
+ See Section 3.4.2, "Message Segmentation and Reassembly".
+
+
+
+
+
+
+Banan Informational [Page 15]
+
+RFC 2524 EMSD February 1999
+
+
+ Content-type
+
+ This argument identifies the type of the content of the message. It
+ identifies the abstract syntax and the encoding rules used.
+
+
+ Content
+
+ This argument contains the information the message is intended to
+ convey to the recipient(s). It shall be generated by the originator
+ of the message.
+
+
+ Results
+
+ This operation's results are:
+
+ SubmitResult ::= SEQUENCE
+
+ {
+ -- Permanent identifier for this message.
+ -- Also contains the message submission time.
+ -- See comment regarding assignment of message identifiers,
+ -- at the definition of EMSDLocalMessageId.
+
+ message-id EMSDLocalMessageId
+
+ };
+
+
+ The fields are:
+
+
+ Message-id
+
+ This result contains an EMSD-SA-identifier that uniquely and
+ unambiguously identifies the message-submission. It shall be
+ generated by the EMSD-SA.
+
+
+ Errors
+
+ See Section 3.4.3.
+
+
+
+
+
+
+
+
+Banan Informational [Page 16]
+
+RFC 2524 EMSD February 1999
+
+
+3.2.2 deliveryControl
+
+ The deliveryControl ES-OPERATION enables the EMSD-UA to temporarily
+ limit the operations that the EMSD-SA may invoke, and the messages
+ that the EMSD-SA may deliver to the EMSD-UA via the Message delivery
+ ES-OPERATION.
+
+ deliveryControl ES-OPERATION
+ ARGUMENT DeliveryControlArgument
+ RESULT DeliveryControlResult
+ ERRORS
+ {
+ securityError,
+ resourceError,
+ protocolViolation
+ } ::= 2;
+
+ The duplicate operation detection is not required for this operation.
+
+ The EMSD-SA shall hold until a later time, rather than abandon, ES-
+ OPERATIONS and messages that are presently suspended.
+
+ The successful completion of the ES-OPERATION signifies that the
+ specified controls are now in force.
+
+ The ES-OPERATION returns an indication of any ES-OPERATIONS that the
+ EMSD-SA would invoke, or any message types that the EMSD-SA would
+ deliver, were it not for the prevailing controls.
+
+
+ Arguments
+
+ This operation's arguments are:
+
+ DeliveryControlArgument ::= SEQUENCE
+ {
+ -- Request an addition of or removal of a set of restrictions
+
+ restrict [0] IMPLICIT Restrict DEFAULT update,
+
+ -- Which operations are to be placed in the restriction set
+ permissible-operations [1] IMPLICIT Operations OPTIONAL,
+
+ -- What maximum content length should be allowed
+ permissible-max-content-length
+
+ [2] IMPLICIT INTEGER
+ (0..ub-content-length) OPTIONAL,
+
+
+
+Banan Informational [Page 17]
+
+RFC 2524 EMSD February 1999
+
+
+ -- What is the lowest priority message which may be delivered
+ permissible-lowest-priority
+
+ [3] IMPLICIT ENUMERATED
+ {
+ non-urgent (0),
+ normal (1),
+ urgent (2)
+ } OPTIONAL,
+
+ -- Security features
+ security [4] IMPLICIT SecurityElement
+ OPTIONAL,
+
+ -- User Feature selection
+ user-features [5] IMPLICIT OCTET STRING
+ OPTIONAL
+ };
+
+
+
+ Restrict
+
+ This argument indicates whether the controls on ES-OPERATIONS are to
+ be updated or removed. It may be generated by the EMSD-UA.
+
+ This argument may have one of the following values:
+
+ o update: The other arguments update the prevailing controls;
+
+ o remove: All temporary controls are to be removed
+
+ In the absence of this argument, the default update shall be assumed.
+
+
+ Permissible-operations
+
+ This argument indicates the ES-OPERATIONS that the EMSD-SA may invoke
+ on the EMSD-UA. It may be generated by the EMSD-UA.
+
+ This argument may have the value allowed or prohibited for each of
+ the following:
+
+ o message-delivery: The EMSD-SA may/may not invoke the deliver
+ ES-OPERATIONS; and
+
+ o Other ES-OPERATIONS are not subject to controls, and may be
+ invoked at any time.
+
+
+
+Banan Informational [Page 18]
+
+RFC 2524 EMSD February 1999
+
+
+ In the absence of this argument, the ES-OPERATIONS that the EMSD-SA
+ may invoke on the EMSD-UA are unchanged.
+
+
+ Permissible-max-content-length
+
+ This argument contains the content-length, in octets, of the
+ longest-content message that the EMSD-SA shall deliver to the EMSD-UA
+ via the deliver ES-OPERATIONS. It may be generated by the EMSD-UA.
+
+ In the absence of this argument, the permissible-maximum-content-
+ length of a message that the EMSD-SA may deliver to the EMSD-UA is
+ unchanged.
+
+
+ Permissible-lowest-priority
+
+ This argument contains the priority of the lowest priority message
+ that the EMSD-SA shall deliver to the EMSD-UA via the deliver ES-
+ OPERATIONS. It may be generated by the EMSD-UA.
+
+ This argument may have one of the following values of the priority
+ argument of the submit ES-OPERATIONS: normal, non-urgent or urgent.
+
+ In the absence of this argument, the priority of the lowest priority
+ message that the EMSD-SA shall deliver to the EMSD-UA is unchanged.
+
+
+ Security
+
+ See Section 3.4.1, "SecurityElements".
+
+
+ User-features
+
+ This argument contains information that allows the EMSD-UA to convey
+ to MTS the feature set that the user is capable of supporting. This
+ argument will be defined when the setConfiguration and
+ getConfiguration operations are defined.
+
+
+ Results
+
+ DeliveryControlResult ::= SEQUENCE
+ {
+ -- Operation types queued at the EMSD-SA due to existing
+ -- restrictions.
+ waiting-operations [0] IMPLICIT Operations DEFAULT { },
+
+
+
+Banan Informational [Page 19]
+
+RFC 2524 EMSD February 1999
+
+
+ -- Types of messages queued at the EMSD-SA due to
+ -- existing restrictions
+ waiting-messages [1] IMPLICIT WaitingMessages
+ DEFAULT { },
+
+ -- Content Types of messages queued at the EMSD-SA
+ waiting-content-types SEQUENCE SIZE (0..ub-content-types) OF
+ ContentType DEFAULT { }
+
+ };
+
+ Restrict ::= ENUMERATED
+ {
+ update (1),
+ remove (2)
+ };
+
+ Operations ::= BIT STRING
+ {
+ submission (0),
+ delivery (1)
+ };
+
+ WaitingMessages ::= BIT STRING
+ {
+ long-content (0),
+ low-priority (1)
+
+
+ };
+
+
+ Waiting-operations
+
+ This result indicates the ES-OPERATIONS being held by the EMSD-SA,
+ and that the EMSD-SA would invoke on the EMSD-UA if it were not for
+ the prevailing controls. It may be generated by the EMSD-SA.
+
+ This result may have the value holding or not-holding for each of the
+ following:
+
+ o message-delivery: The EMSD-SA is/is not holding messages, and
+ would invoke the deliver ES-OPERATIONS on the EMSD-UA if it were
+ not for the prevailing controls.
+
+ In the absence of this result, it may be assumed that the EMSD-SA is
+ not holding any messages for delivery due to the prevailing controls.
+
+
+
+
+Banan Informational [Page 20]
+
+RFC 2524 EMSD February 1999
+
+
+ Waiting-messages
+
+ This result indicates the kind of messages the EMSD-SA is holding for
+ delivery to the EMSD-UA, and would deliver via the deliver ES-
+ OPERATIONS, if it were not for the prevailing controls. It may be
+ generated by the EMSD-SA.
+
+ This result may have one or more of the following values:
+
+ o long-content: The EMSD-SA has messages held for delivery to the
+ EMSD-UA which exceed the permissible maximum-content-length
+ control currently in force;
+
+ o low-priority: The EMSD-SA has messages held for delivery to the
+ EMSD-UA of a lower priority than the permissible-lowest-priority
+ control currently in force;
+
+ In the absence of this result, it may be assumed that the EMSD-SA is
+ not holding any messages for delivery to the EMSD-UA due to the
+ permissible-maximum-content-length, permissible-lowest-priority or
+ permissible-security context controls currently in force.
+
+ Errors
+
+ See Section 3.4.3.
+
+3.2.3 deliveryVerify
+
+ The deliveryVerify ES-OPERATIONS enables the EMSD-UA to verify
+ delivery of a message when it receives FAILURE.indication for deliver
+ ES-OPERATIONS.
+
+ deliveryVerify ES-OPERATION
+
+ ARGUMENT DeliveryVerifyArgument
+ RESULT DeliveryVerifyResult
+ ERRORS
+ {
+ verifyError,
+ resourceError,
+ protocolViolation
+ } ::= 5;
+
+ The duplicate operation detection is not required for this operation.
+
+
+ Arguments
+
+
+
+
+Banan Informational [Page 21]
+
+RFC 2524 EMSD February 1999
+
+
+ This operation's arguments are:
+
+ DeliveryVerifyArgument ::= SEQUENCE
+
+ {
+ -- Identifier of this message. This is the same identifier that
+ -- was provided to the originator in the Submission Result.
+ -- See comment regarding assignment of message identifiers,
+ -- at the definition of EMSDMessageId.
+ message-id EMSDMessageId
+ };
+
+
+ Message-id
+
+ This argument contains an EMSD-SA-identifier that distinguishes the
+ message from all other messages. It shall be generated by the EMSD-
+ SA, and shall have the same value as the message-submission-
+ identifier supplied to the originator of the message when the message
+ was submitted.
+
+
+ Results
+
+ DeliveryVerifyResult ::= SEQUENCE
+ {
+ status DeliveryStatus
+ };
+
+ DeliveryStatus ::= ENUMERATED
+ {
+ no-report-is-sent-out (1),
+ delivery-report-is-sent-out (2),
+ non-delivery-report-is-sent-out (3)
+ };
+
+
+
+ No-report-is-sent-out
+
+ This result indicates that EMSD-SA has received the delivery verify
+ and no report is sent out (either because it has not been requested
+ or EMSD-SA has problems and can not send it out).
+
+
+ Delivery-report-is-sent-out
+
+ This result indicates that EMSD-SA has received the delivery verify
+
+
+
+Banan Informational [Page 22]
+
+RFC 2524 EMSD February 1999
+
+
+ and has sent the delivery report out.
+
+
+ Non-Delivery-report-is-sent-out
+
+ This result indicates that EMSD-SA has received the delivery verify
+ but it has already sent out a non-Delivery report. This should not
+ happen in normal cases but a wrong user profile on EMSD-SA side can
+ result in this outcome.
+
+ Errors
+
+ See Section 3.4.3.
+
+
+3.3 EMSD-SA Invoked Operations
+
+ This section defines the operations invoked by the EMSD-SA:
+
+ a. deliver;
+
+ b. submissionControl;
+
+ c. submissionVerify.
+
+ The deliver operation uses 3-Way handshake service of ESROS. This
+ operation always uses the duplication detection functional unit.
+
+ The submissionControl and submissionVerify operations use 2-Way
+ handshake service of ESROS without duplication detection.
+
+3.3.1 deliver
+
+ The deliver ES-OPERATIONS enables the EMSD-SA to deliver a message to
+ an EMSD-UA.
+
+ deliver ES-OPERATION
+
+ ARGUMENT DeliverArgument
+ RESULT NULL
+ ERRORS
+ {
+ deliveryControlViolated,
+ securityError,
+ resourceError,
+ protocolViolation,
+ messageError
+ } ::= 35;
+
+
+
+Banan Informational [Page 23]
+
+RFC 2524 EMSD February 1999
+
+
+ The EMSD-UA MUST not refuse performing the deliver ES-OPERATION
+ unless the delivery would violate the deliveryControl restrictions
+ then in force.
+
+
+ Arguments
+
+ This operation's arguments are:
+
+ DeliverArgument ::= SEQUENCE
+ {
+ -- Identifier of this message. This is the same identifier that
+ -- was provided to the originator in the Submission Result.
+ -- See comment regarding assignment of message identifiers,
+ -- at the definition of EMSDMessageId.
+ message-id EMSDMessageId,
+
+ -- Time the message was delivered to the recipient by EMSD-SA
+ message-delivery-time DateTime,
+
+ -- Time EMSD-SA originally took responsibility for processing
+ -- of this message. This field shall be omitted if the message-id
+ -- contains an EMSDLocalMessageId, because that field contains
+ -- the submission time within it.
+ message-submission-time [0] IMPLICIT DateTime OPTIONAL,
+
+ -- Security features
+ security [1] IMPLICIT SecurityElement OPTIONAL,
+
+ -- SegContentTypementation features for efficient transport
+ segment-info SegmentInfo OPTIONAL,
+
+ -- The type of the content
+ content-type ContentType,
+
+ --
+ -- THE CONTENT --
+ --
+
+ -- The submitted (and now being delivered) content
+ content ANY DEFINED BY content-type
+ };
+
+
+
+
+
+
+
+
+
+Banan Informational [Page 24]
+
+RFC 2524 EMSD February 1999
+
+
+ message-id
+
+ This argument contains an EMSD-SA-identifier that distinguishes the
+ message from all other messages. When within the EMSD, it MUST be
+ generated by the EMSD-SA, and MUST have the same value as the
+ message-submission-identifier supplied to the originator of the
+ message when the message was submitted.
+
+
+ Message-delivery-time
+
+ This argument contains the Time at which delivery occurs and at which
+ the EMSD-SA is relinquishing responsibility for the message. It
+ shall be generated by the EMSD-SA.
+
+
+ Results
+
+ This operation returns an empty result as indication of success.
+
+
+ Errors
+
+ See Section 3.4.3.
+
+
+3.3.2 submissionControl
+
+ submissionControl ES-OPERATION
+ ARGUMENT SubmissionControlArgument
+ RESULT SubmissionControlResult
+ ERRORS
+ {
+ securityError,
+ resourceError,
+ protocolViolation
+ } ::= 4;
+
+ The submissionControl ES-OPERATIONS enables the EMSD-SA to
+ temporarily limit the operations that the EMSD-UA may invoke, and the
+ messages that the EMSD-UA may submit to the EMSD-SA via the submit
+ ES-OPERATIONS.
+
+ The duplicate operation detection is not required for this operation.
+
+ The EMSD-UA should hold until a later time, rather than abandon, ES-
+ OPERATIONS and messages that are presently suspended.
+
+
+
+
+Banan Informational [Page 25]
+
+RFC 2524 EMSD February 1999
+
+
+ The successful completion of the ES-OPERATIONS signifies that the
+ specified controls are now in force. These controls supersede any
+ previously in force, and remain in effect until the association is
+ released or the EMSD-SA re-invokes the submissionControl ES-
+ OPERATIONS.
+
+ The ES-OPERATIONS returns an indication of any ES-OPERATIONS that the
+ EMSD-UA would invoke were it not for the prevailing controls.
+
+
+ Arguments
+
+ This operation's arguments are:
+
+ SubmissionControlArgument ::= SEQUENCE
+ {
+ -- Request an addition of or removal of a set of restrictions
+ restrict [0] IMPLICIT Restrict DEFAULT update,
+
+ -- Which operations are to be placed in the restriction set
+ permissible-operations [1] IMPLICIT Operations OPTIONAL,
+
+ -- What maximum content length should be allowed
+ permissible-max-content-length
+ [2] IMPLICIT INTEGER
+ (0..ub-content-length) OPTIONAL,
+
+ -- Security features
+ security [3] IMPLICIT SecurityElement
+ OPTIONAL
+ };
+
+
+
+ Restrict
+
+ This argument indicates whether the controls on ES-OPERATIONS are to
+ be updated or removed. It may be generated by the EMSD-SA.
+
+ This argument may have one of the following values:
+
+ o update: The other arguments update the prevailing controls;
+
+ o remove: All temporary controls are to be removed
+
+ In the absence of this argument, the default update shall be assumed.
+
+
+
+
+
+Banan Informational [Page 26]
+
+RFC 2524 EMSD February 1999
+
+
+ Permissible-operations
+
+ This argument indicates the ES-OPERATIONS that the EMSD-UA may invoke
+ on the EMSD-SA. It may be generated by the EMSD-SA.
+
+ This argument may have the value allowed or prohibited for each of
+ the following:
+
+ o submit: The EMSD-UA may/may not invoke the submit ES-
+ OPERATIONS; and
+
+ o Other ES-OPERATIONS are not subject to controls, and may be
+ invoked at any time.
+
+ In the absence of this argument, the ES-OPERATIONS that the EMSD-UA
+ may invoke on the EMSD-SA are unchanged.
+
+
+ Permissible-max-content-length
+
+ This argument contains the content-length, in octets, of the
+ longest-content message that the EMSD-UA shall submit to the EMSD-SA
+ via the submit ES-OPERATIONS. It may be generated by the EMSD-SA.
+
+ In the absence of this argument, the permissible-maximum-content-
+ length of a message that the EMSD-UA may submit to the EMSD-SA is
+ unchanged.
+
+
+ Security
+
+ See Section 3.4.1, "SecurityElements".
+
+
+ Results
+
+ SubmissionControlResult ::= SEQUENCE
+ {
+ -- Operation types queued at the EMSD-SA due to existing
+ -- restrictions.
+ waiting-operations [0] IMPLICIT Operations DEFAULT { }
+
+ };
+
+
+
+
+
+
+
+
+Banan Informational [Page 27]
+
+RFC 2524 EMSD February 1999
+
+
+ Waiting-operations
+
+ This result indicates the ES-OPERATIONS being held by the EMSD-UA,
+ and that the EMSD-UA would invoke if it were not for the prevailing
+ controls. It may be generated by the EMSD-UA.
+
+ This result may have the value holding or not-holding for each of the
+ following:
+
+ o submit: The EMSD-UA is/is not holding messages, and would
+ invoke the submit ES-OPERATIONS if it were not for the
+ prevailing controls.
+
+ In the absence of this result, it may be assumed that the EMSD-UA is
+ not holding any messages for submission due to the prevailing
+ controls.
+
+
+ Errors
+
+ See Section 3.4.3.
+
+
+3.3.3 submissionVerify
+
+ The submissionVerify ES-OPERATIONS enables the EMSD-SA to verify if
+ the EMSD-UA has received the result of its submission.
+
+ submissionVerify ES-OPERATION
+
+ ARGUMENT SubmissionVerifyArgument
+ RESULT SubmissionVerifyResult
+ ERRORS
+ {
+ submissionVerifyError,
+ resourceError,
+ protocolViolation
+ } ::= 6;
+
+ The duplicate operation detection is not required for this operation.
+
+
+ Arguments
+
+ This operation's arguments are:
+
+
+ SubmissionVerifyArgument ::= SEQUENCE
+
+
+
+Banan Informational [Page 28]
+
+RFC 2524 EMSD February 1999
+
+
+ -- Identifier of this message. This is the same identifier that
+ -- was provided to the originator in the Submission Result.
+ -- See comment regarding assignment of message identifiers,
+ -- at the definition of EMSDMessageId.
+ {
+ message-id EMSDMessageId
+ };
+
+
+ Message-id
+
+ This argument contains an EMSD-SA-identifier that distinguishes the
+ message from all other messages. It shall be generated by the EMSD-
+ SA, and shall have the same value as the message-submission-
+ identifier supplied to the originator of the message when the message
+ was submitted.
+
+
+ Results
+
+ SubmissionVerifyResult ::= SEQUENCE
+ {
+ status SubmissionStatus
+ };
+
+ SubmissionStatus::= ENUMERATED
+ {
+ send-message (1),
+ drop-message (2)
+ };
+
+
+ Send-message
+
+ This result indicates that EMSD-SA is supposed to send the message
+ out.
+
+
+ Drop-message
+
+ This result indicates that EMSD-SA is supposed to drop the message.
+
+
+ Errors
+
+ See Section 3.4.3.
+
+
+
+
+
+Banan Informational [Page 29]
+
+RFC 2524 EMSD February 1999
+
+
+3.4 EMSD Common Information Objects
+
+3.4.1 SecurityElements
+
+ SecurityElement ::= SEQUENCE
+
+ {
+ credentials Credentials,
+ contentIntegrityCheck ContentIntegrityCheck OPTIONAL
+ };
+
+ Credentials ::= CHOICE
+ {
+ simple [0] IMPLICIT SimpleCredentials
+
+ -- Strong Credentials are for future study
+ -- strong [1] IMPLICIT StrongCredentials
+ -- externalProcedure [2] EXTERNAL
+ };
+
+ SimpleCredentials ::= SEQUENCE
+ {
+ eMSDAddress EMSDAddress OPTIONAL,
+ password [0] IMPLICIT OCTET STRING
+ SIZE (0..ub-password-length)) OPTIONAL
+ };
+
+ -- StrongCredentials ::= NULL
+ -- for now.
+ -- ContentIntegrityCheck is a 16-bit checksum of content
+ ContentIntegrityCheck ::= INTEGER (0..65535);
+
+3.4.2 Message Segmentation and Reassembly
+
+ Small messages can benefit from the efficiencies of connectionless
+ feature of ESROS (See Efficient Short Remote Operations, RFC-2188
+ [1]).
+
+ Very large messages are transferred using protocols (e.g., SMTP) that
+ rely on Connection Oriented Transport Service (e.g., TCP).
+
+ When a message is too large to fit in a single connectionless PDU but
+ is not large enough to justify the overhead of connection
+ establishment, it may be more efficient for the message to be
+ segmented and reassembled while the connectionless service of ESROS
+ is used. If the underlying Remote Operation Service is capable of
+ efficient segmentation/reassembly over connectionless (CL) services,
+
+
+
+
+Banan Informational [Page 30]
+
+RFC 2524 EMSD February 1999
+
+
+ then use of the segmenting/reassembly mechanism introduced in this
+ section is not necessary. This feature is accommodated in this layer
+ by:
+
+ SegmentInfo ::= CHOICE
+
+ {
+ first [APPLICATION 2] IMPLICIT FirstSegment,
+ other [APPLICATION 3] IMPLICIT OtherSegment
+ };
+
+ FirstSegment ::= SEQUENCE
+ {
+ sequence-id INTEGER,
+ number-of-segments INTEGER
+ -- number-of-segments must not exceed ub-total-number-of-segments
+ };
+
+ OtherSegment ::= SEQUENCE
+ {
+ sequence-id INTEGER,
+ segment-number INTEGER
+ };
+
+ Segmentation and reassembly only applies to Message-submission and
+ Message-delivery.
+
+ The sender of the message is responsible for segmenting the message
+ content into segments that fit in CL PDUs. The segmented content is
+ sent in a sequence of message-segments each carrying a segment of the
+ content. sequence-Id is a unique identifier that is present in all
+ message-segments. In addition to sequence identifier, the first
+ message-segment specifies the total number of segments (number-of-
+ segments). Other message-segments have a segment sequence number
+ (segment-number). The receiver is responsible for sequencing (based
+ on segment-number) and reassembling the entire message.
+
+
+ Segmenting over the Connectionless ESRO Service
+
+ The sender of the message maps the original message into an ordered
+ sequence of message-segments. This sequence shall not be interrupted
+ by other messages over the same ESROS association.
+
+ All message-segments in the sequence shall be assigned a sequence
+ identifier by sender. The sequence identifier shall be incremented
+ by one by the sender after transmission of a complete message
+ sequence.
+
+
+
+Banan Informational [Page 31]
+
+RFC 2524 EMSD February 1999
+
+
+ The first message-segment specifies the total number of segments.
+ All message-segments in the sequence except the first one shall be
+ sequentially numbered, starting at 1 (first message-segment has
+ implicit segment number of 0).
+
+ Each message-segment is transmitted by issuing a Message-submission
+ or Message-delivery ES-OPERATIONS. All segments of a segmented
+ message are identified by the same sequence-id. For a given message,
+ the receiver should not impose any restriction on the order of
+ arrival of message-segments.
+
+ There is no requirement that any message-segment content be of
+ maximum length allowed by ESROS for connectionless transmission;
+ however, no more than ub-total-number-of-segments segments can be
+ derived from a single message.
+
+ The receiver reassembles a sequence of message-segments into a single
+ message. A message shall not be further processed unless all
+ segments of the message are received. Failure to receive the message
+ shall be determined by the following events:
+
+ o Expiration of Reassembly Timer (see Section 3.4.3).
+
+ o Receipt of a message-segment with different sequence identifier.
+
+ In the event of the above mentioned failures, the receiver shall
+ discard a partially assembled sequence.
+
+ In Reassembly process, all arguments other than content are ignored
+ in all segments except the first one. The content parts of all
+ segments are concatenated to compose the original message content.
+
+ When sender receives FAILURE.indication (as opposed to a
+ resourceError) for a message-segment, the whole message shall be
+ retransmitted.
+
+ In the case of submission and delivery operations, the verify
+ function is used as described below:
+
+ Receiver ignores FAILURE.indications received for message-segments,
+ and just collects the message-segments to complete the message.
+ However, it keeps a failure status for a segmented message which says
+ if any segment of the message has received FAILURE.indication. When
+ receiver succeeds to assemble the whole segmented message, then if
+ the status of the message shows there has been a FAILURE.indication
+ for any of the message-segments, it verifies the message through
+ verify operation. It's not enough to invoke verify operation just
+ based on the last message-segment because the sender might send a
+
+
+
+Banan Informational [Page 32]
+
+RFC 2524 EMSD February 1999
+
+
+ segment without waiting for the result of the previous segment. In
+ such cases, there might be any combination of success and failure for
+ message-segments on the sender side.
+
+ Receiver uses the error code ResourceError (see Section 3.4.3) to ask
+ for retransmission of a single segment and uses the error code
+ MessageError (see Section 3.4.3) to ask for retransmission of all
+ segments (the whole message).
+
+
+ Reassembly Timer
+
+ The Reassembly Timer is a local timer maintained by the receiver of
+ message-segments that assists in performing the reassembly function.
+ This timer determines how long a receiver waits for all segments of a
+ message-segment sequence to be received. The timer protects the
+ receiver from the loss of a series of segments and possible sequence
+ identifier wrap-around.
+
+ The Reassembly Timer shall be started on receipt of a message-segment
+ with different sequence identifier than that previously received.
+ The timer shall be stopped on receipt of all segments composing the
+ sequence.
+
+ The value of Reassembly Timer is defined based on the network
+ characteristics and the number of segments. This requires that the
+ transmission of all segments of a single message must be completed
+ within this time limit.
+
+3.4.3 Common Errors
+
+ protocolVersionNotRecognized ERROR PARAMETER NULL ::= 1;
+
+ submissionControlViolated ERROR PARAMETER NULL ::= 2;
+
+ messageIdentifierInvalid ERROR PARAMETER NULL ::= 3;
+
+ securityError ERROR PARAMETER security-problem SecurityProblem ::= 4;
+
+ deliveryControlViolated ERROR PARAMETER NULL ::= 5;
+
+ resourceError ERROR PARAMETER NULL ::= 6;
+
+ protocolViolation ERROR PARAMETER NULL ::= 7;
+
+ messageError ERROR PARAMETER NULL ::= 8;
+
+ SecurityProblem ::= INTEGER (0..127);
+
+
+
+Banan Informational [Page 33]
+
+RFC 2524 EMSD February 1999
+
+
+ protocolVersionNotRecognized
+
+ The major and minor protocol versions presented do not match those
+ recognized as being valid.
+
+
+ submissionControlViolated
+
+ The Submission control violated error reports the violation by the
+ MTS-user of a control on submission services imposed by the MTS via
+ the Submission control service. The Submission control violated
+ abstract-error has no parameters.
+
+
+ messageIdentifierInvalid
+
+ The Message Identifier Invalid error reports that the Message
+ Identifier presented to the MTS is not considered valid.
+
+
+ securityError
+
+ The Security error reports that the requested operation could not be
+ provided by the MTS or MTS-user because it would violate the security
+ policy in force.
+
+
+ deliveryControlViolated
+
+ The Delivery control violated error reports the violation by the MTS
+ of a control on delivery operations imposed by the MTS-user via the
+ Delivery-control operation.
+
+
+ resourceError
+
+ The messaging agent cannot currently support this operation. In the
+ case of segmentation and reassembly, resourceError is by the receiver
+ used to request that the sender retransmit of a single segment.
+
+
+ protocolViolation
+
+ Indicates that one or more mandatory argument(s) were missing.
+
+
+
+
+
+
+
+Banan Informational [Page 34]
+
+RFC 2524 EMSD February 1999
+
+
+ messageError
+
+ For a multi-segment message, this error indicates that the messaging
+ agent has not received the message completely and that the message
+ must be retransmitted.
+
+
+ SecurityProblem
+
+ To ensure the security-policy is not violated during delivery, the
+ message-security-label is checked against the security-context. If
+ delivery is barred by the security-policy then, subject to the
+ security policy, a report instruction for this is generated.
+
+3.4.4 ContentType
+
+ ContentType ::= INTEGER
+ {
+ -- Content type 0 is reserved and shall never be transmitted.
+ reserved (0),
+ -- Content types between 1 and 31 (inclusive) are for
+ -- internal-use only
+ probe (1), -- reserved
+ delivery-report (2), -- reserved
+
+ -- Content types between 32 and 63 (inclusive) are for
+ -- message types defined within this specifications.
+ emsd-interpersonal-messaging-1995 (32),
+ voice-messaging (33) -- reserved
+
+ -- Content types beyond and including 64 are for
+ -- bilaterally-agreed use between peers.
+ } (0..127);
+
+3.4.5 EMSDMessageId
+
+ If this message was originated as an RFC-822 message, then this
+ EMSDMessageId shall be the "Message-Id:" field from that message. If
+ this message was originated within the EMSD domain, then this
+ identifier shall be unique for the EMSD-SA generating this id.
+
+ EMSDMessageId ::= CHOICE
+ {
+ EMSDLocalMessageId [APPLICATION 4]
+ IMPLICIT EMSDLocalMessageId,
+
+ rfc822MessageId [APPLICATION 5]
+ IMPLICIT AsciiPrintableString
+
+
+
+Banan Informational [Page 35]
+
+RFC 2524 EMSD February 1999
+
+
+ (SIZE (0..ub-message-id-length))
+ };
+
+ EMSDLocalMessageId ::= SEQUENCE
+ {
+ submissionTime DateTime,
+ messageNumber INTEGER (0..ub-local-message-nu)
+ };
+
+3.4.6 EMSDORAddress
+
+ EMSDORAddress ::= CHOICE
+ {
+ -- This is the local-format address
+ emsd-local-address-format EMSDAddress,
+
+ -- This is a globally-unique RFC-822 Address
+ rfc822DomainAddress AsciiPrintableString
+ };
+
+ In the global sense Originators and Recipients are represented by
+ EMSDORAddress. The rfc822Domain may be used to address any
+ recipient.
+
+3.4.7 EMSDAddress
+
+ EMSDAddress ::= SEQUENCE
+ {
+ emsd-address OCTET STRING (SIZE
+ (1..ub-emsd-address-length)),
+ -- emsd-address is a decimal integer in BCD
+ (Binary Encoded Decimal) format.
+ -- If it had an odd number of digits, it is
+ -- padded with 0 on the left.
+
+ emsd-name [0] IMPLICIT OCTET STRING
+ (SIZE (0..ub-emsd-name-length))
+ OPTIONAL
+ };
+
+ Originator and Recipients in the scope of EMSD network are identified
+ by a digit based addressing scheme. EMSDAddress can only be used
+ where the scope of addressing has clearly been limited to the EMSD
+ network.
+
+3.4.8 DateTime
+
+ DateTime ::= INTEGER;
+
+
+
+Banan Informational [Page 36]
+
+RFC 2524 EMSD February 1999
+
+
+ DateTime is a Julian date, expressed as the number of seconds since
+ 00:00:00 UTC, January 1, 1970.
+
+3.4.9 AsciiPrintableString
+
+ Iso8859String ::= GeneralString;
+
+ AsciiPrintableString ::= [APPLICATION 0]
+ IMPLICIT Iso8859String (FROM
+
+ (" "|"!"|"#"|"$"|"%"|"&"|"'"|"("|")"|"*"|"+"|","|"-"|"."|"/"|
+ "0"|"1"|"2"|"3"|"4"|"5"|"6"|"7"|"8"|"9"|":"|";"|"<"|"="|">"|
+ "?"|"@"|"A"|"B"|"C"|"D"|"E"|"F"|"G"|"H"|"I"|"J"|"K"|"L"|"M"|
+ "N"|"O"|"P"|"Q"|"R"|"S"|"T"|"U"|"V"|"W"|"X"|"Y"|"Z"|"["|"]"|
+ "^"|"_"|"`"|"a"|"b"|"c"|"d"|"e"|"f"|"g"|"h"|"i"|"j"|"k"|"l"|
+ "m"|"n"|"o"|"p"|"q"|"r"|"s"|"t"|"u"|"v"|"w"|"x"|"y"|"z"|"{"|
+ "|"|"}"|"~"|"\"|""""));
+
+3.4.10 ProtocolVersionNumber
+
+ ProtocolVersionNumber ::= [APPLICATION 1] SEQUENCE
+ {
+ version-major INTEGER,
+
+ +------------------+-------+----+---------+----+---------+-----+-----+
+ |Operation |Invoker|Sap |Performer|Sap |Duplicate|OpId |ESROS|
+ | | |Sel | |Sel |Detect | |Use |
+ |__________________|_______|____|_________|____|_________|_____|_____|
+ |submit |UA |4 |MTS |5 |Yes |33 |3-Way|
+ |__________________|_______|____|_________|____|_________|_____|_____|
+ |deliver |MTS |2 |UA |3 |Yes |35 |3-Way|
+ |__________________|_______|____|_________|____|_________|_____|_____|
+ |deliveryControl |UA |8 |MTS |9 |No |2 |2-Way|
+ |__________________|_______|____|_________|____|_________|_____|_____|
+ |submissionControl |MTS |6 |UA |7 |No |4 |2-Way|
+ |__________________|_______|____|_________|____|_________|_____|_____|
+ |submissionVerify |MTS |6 |UA |7 |No |6 |2-Way|
+ |__________________|_______|____|_________|____|_________|_____|_____|
+ |deliveryVerify |UA |8 |MTS |9 |No |5 |2-Way|
+ |__________________|_______|____|_________|____|_________|_____|_____|
+ |getConfiguration |UA |8 |MTS |9 |No |7 |2-Way|
+ |__________________|_______|____|_________|____|_________|_____|_____|
+ |setConfiguration |MTS |6 |UA |7 |No |8 |2-Way|
+ +------------------+-------+----+---------+----+---------+-----+-----+
+
+ Table 1: EMSD-P Operations Summary
+
+
+
+
+
+Banan Informational [Page 37]
+
+RFC 2524 EMSD February 1999
+
+
+ version-minor [0] IMPLICIT INTEGER DEFAULT 0
+ }
+
+3.5 Submission and Delivery Procedures
+
+ Table 1 provides a comprehensive summary of EMSD-P operations, the
+ SAP selectors used and the operation IDs used.
+
+
+ Submission
+
+ The semantics of a submission operation is Exactly Once. Exactly
+ Once means that every operation is carried out exactly one time, no
+ more and no less. This semantic can not be fully implemented
+ because, if after invoking the operation, an invoker has a Success
+ (e.g. result) indication and the performer has a FAILURE.indication,
+ and the network goes down, the result of the operation will be Zero
+ (and not Exactly Once).
+
+ No more than one is controlled and guaranteed by the performer by
+ using the Duplicate Operation Detection Support Functions (see the
+ chapter entitled Duplicate Operation Detection Support).
+
+ Not zero but one is realized by performer by using the
+ SubmissionVerify operation. When the performer receives
+ FAILURE.indication, it's responsibility is to resolve the case by
+ using SubmissionVerify resulting in Not zero but one.
+
+ Submission procedure is as follows:
+
+ o Submit operation with 3-Way handshake and Duplicate Operation
+ Detection Support Function is invoked.
+
+ o If performer at EMSD-SA receives FAILURE.indication, it invokes
+ SubmissionVerify.
+
+ o Message is sent out by EMSD-SA only if result operation is
+ confirmed or the operation is verified (in the case of
+ FAILURE.indication).
+
+ The semantic of SubmissionVerify operation is At Least Once. This
+ type of semantics corresponds to the case that invoker keeps trying
+ over and over until it gets a proper reply. This operation can be
+ performed more than once without any harm.
+
+
+
+
+
+
+
+Banan Informational [Page 38]
+
+RFC 2524 EMSD February 1999
+
+
+ Implications:
+
+ o MTS sends out the message if and only if it's sure that UA knows
+ about it.
+
+
+ Delivery
+
+ The semantics of Deliver operation is Exactly Once. Exactly Once
+ means that every operation is carried out exactly one time, no more
+ and no less. This semantic can not be fully implemented and if after
+ invoking the operation, invoker has Success indication and performer
+ has FAILURE.indication, and the network goes down, the result of the
+ operation will be Zero (and not Exactly Once).
+
+ No more than one is controlled and guaranteed by performer and by
+ using the Duplicate Operation Detection Support Functions.
+
+ Not zero but one is realized by performer by using the DeliveryVerify
+ operation. When performer receives FAILURE.indication, it's
+ responsible to resolve the case by using DeliveryVerify resulting in
+ Not zero but one.
+
+ Delivery procedure is as follows:
+
+ o Deliver operation with 3-Way handshake is invoked.
+
+ o If performer at User Agent (device) receives FAILURE.indication,
+ it invokes DeliveryVerify.
+
+ The semantic of DeliveryVerify operation is At Least Once. This type
+ of semantics corresponds to the case that invoker keeps trying over
+ and over until it gets a proper reply. This operation can be
+ performed more than once without any harm.
+
+ Implications:
+
+ o A non-delivery report is sent by MTS only if the message is not
+ delivered.
+
+ o The UA is responsible for notifying the MTS (through an explicit
+ deliveryVerify) to make sure that a delivery report is sent out.
+
+
+
+
+
+
+
+
+
+Banan Informational [Page 39]
+
+RFC 2524 EMSD February 1999
+
+
+4 DUPLICATE OPERATION DETECTION SUPPORT
+
+4.1 Duplicate Operation Detection Support Overview
+
+ Some operations are idempotent in nature, i.e. they can be performed
+ more than once without any harm. However, some other operations are
+ non-idempotent in nature, i.e. they should be performed only once.
+ In the case of non-idempotent operations, performer should be able to
+ detect duplicate operations and perform each non-idempotent operation
+ only once.
+
+ Examples of non-idempotent operations are Submission and Delivery of
+ messages which shouldn't be performed more than once. Examples of
+ idempotent operations are Submission-control and Delivery-control
+ which can be performed more than once with no harm.
+
+ ESRO Services don't detect duplicate invocation of operations. As a
+ result, the Duplicate Operation Detection Support Functional Unit is
+ used to detect duplication when the same operation instance is
+ invoked more than once. Invoker assigns an Operation Instance
+ Identifier to an operation and this Operation Instance Identifier is
+ used at the peer performer entity to detect the duplicate invocation
+ of the same operation.
+
+ Using this support, non-idempotent operations can be repeated over
+ and over with no harm because the duplicate invocations are detected
+ by this functional unit. This support helps the performer not to
+ perform an operation more than once.
+
+ Support for duplication detection is realized through allocating
+ Operation Instance Id (see Section 4.1.2, "Operation Instance
+ Identifier") to an operation by invoker. When an operation is
+ invoked using duplication detection support, performer logs the
+ Operation Instance Identifier and checks the next operations against
+ duplication.
+
+ Operation value identifies whether performer should detect duplicate
+ operations (see Section 4.1.1, "Operation Value") and Operation
+ Instance Id is assigned by invoker and sent as the first byte of
+ operation's parameter.
+
+4.1.1 Operation Value
+
+ Operation Values are divided into two groups. Operation values from
+ 0 to 31 do not have Duplicate Operation Detection Support (0 to 31)
+ and operation values from 32 to 63 have Duplicate Operation Detection
+ Support.
+
+
+
+
+Banan Informational [Page 40]
+
+RFC 2524 EMSD February 1999
+
+
+ Duplicate Operation Detection Functional Unit checks for duplication
+ only if Operation Value is in the range of 32 to 63.
+
+ When invoker user uses an Operation Value in the range of 32 to 63
+ which means operation with support for duplication detection, the
+ user should specify an Operation Instance ID for the operation (see
+ next section).
+
+4.1.2 Operation Instance Identifier
+
+ To support duplication detection, an Operation Instance Identifier is
+ assigned by invoker user and sent as the first byte of the
+ operation's parameter. This identifier is used on performer side to
+ detect duplicate invocation of the same operation. Characteristics
+ of Operation Instance Identifier is as follows:
+
+ o Operation Instance Identifier is one byte and can have values
+ from 0 to 255.
+
+ o Operation Instance Identifier is sent as the first byte of the
+ operations parameter (without encoding).
+
+ o The length of Operation Instance Identifier is 8-bit, but
+ depending on the performer capabilities, it might keep 0 to 127
+ Operation Instance Identifiers for duplication detection. The
+ performer profile defines the number of outstanding Operation
+ Instance Identifiers that are checked against duplication. When
+ a performer profile indicates support for 0 outstanding
+ Operation Instance Identifier, it means it does not have support
+ for Duplicate Operation Detection. In this case, there should
+ be only one outstanding operation at any point of time.
+
+ o Instance ID check is not part of ESROS, per se. Use of
+ Duplicate Detection is determined by EMSD-P. Operation Instance
+ ID for operations 32-63 is the first byte of the argument.
+ Duplicate Detection suuport strips that byte.
+
+ o The Instance ID is not subject to Basic Encoding Rules (BER).
+
+ o The invoker user assigns the Operation Instance Identifier to
+ the operation at the time of requesting the invoke service. The
+ Operation Value should be in the range of operation values with
+ duplication detection support, i.e. 32 to 63.
+
+ o It's the responsibility of the user to choose Operation Instance
+ Identifier in a way that uniqely and unambiguously identifies
+ the operation.
+
+
+
+
+Banan Informational [Page 41]
+
+RFC 2524 EMSD February 1999
+
+
+ o From the invoker's perspective, assumption is that two
+ operations with the same operation Instance Identifier are
+ totally identical which means they produce exact same results.
+
+ o Operation Instance Identifier uniqely specifies a non-idempotent
+ operation and multiple invocations of such an operation will
+ eventually result in the same outcome because the duplicate
+ instances are identified and the operation is not performed more
+ than once.
+
+ o From the performer's perspective, assumption is that two
+ operations with the same Operation Instance Identifier should be
+ executed once and once only.
+
+ o If requested, the degree of duplication checked by Duplicate
+ Operation Detection Support Functional Unit on the performer's
+ side (i.e. the total number of outstanding Operation Instance
+ Identifier kept) can be communicated with the invoker to
+ synchronize the invocations.
+
+ o User of Duplicate Operation Detection Support is responsible to
+ behave based on the performer profile and its limitations in
+ this regard. This behavior is defined based on the desired
+ semantic of the operation which is to be implemented.
+
+ o On the performer side, when an Operation Instance Identifier is
+ received, a previous Operation Instance Identifier whose
+ distance to this latest one is greater than or equal to half of
+ the wrap-around range of the Operation Instance Identifier
+ number is expired, i.e. for an 8-bit Operation Instance
+ Identifier, the distance of 128 causes an old Operation Instance
+ Identifier to expire.
+
+ o It's the responsibility of the invoker user to use consecutive
+ Operation Instance Identifier numbers, or when it skips some
+ Operation Instance Identifiers, it should remember that if there
+ is an smaller Operation Instance Identifier on performer side
+ with the distance explained above, it will be expired.
+
+5 EMSD PROCEDURE FOR OPERATIONS
+
+ The following sections shows the general procedures to be used in the
+ implementation of the EMSD Message Transfer Server (MTS) and the EMSD
+ User Agent (UA), with the option for 3-Way or 2-Way handshakes on
+ operations which support them. These procedures do not constitute
+ complete behavior specifications for implementations. The following
+ sections contain information helpful to implementors.
+
+
+
+
+Banan Informational [Page 42]
+
+RFC 2524 EMSD February 1999
+
+
+ The MTS and the UA are event-driven. Each waits for any of the
+ possible event types, and, upon receiving an event, processes it.
+ After processing the event, the next event is waited upon.
+
+5.1 MTS Behavior
+
+ The MTS is event-driven.
+
+ If it received an event from ESROS, then it could be any of the
+ following types:
+
+ o Message submit indication;
+
+ o Message submit confirm and failure indication;
+
+ o Result and Error indication for a deliver operation;
+
+ o DeliveryVerify indication;
+
+ o Result and Error indication for a submissionVerify operation;
+
+ o Result and Error indication for a submissionControl operation;
+
+ o DeliveryControl indication.
+
+ For an ESROS event responsibility is passed to the MTS performer
+ (Section 5.1.1).
+
+ If the MTS received an event:
+
+ o for message delivery, from the RFC-822 mailer;
+
+ o requesting submission controls upon the UA, or;
+
+ o indicating an elapsed timer (meaning that it's time to re-
+ attempt a message delivery)
+
+ then responsibility is passed to the MTS invoker (Section 5.1.5).
+
+5.1.1 MTS Performer
+
+ The MTS performer is responsible for processing the following
+ operations, received from ESROS:
+
+ o Message-submission
+
+ o Delivery-control
+
+
+
+
+Banan Informational [Page 43]
+
+RFC 2524 EMSD February 1999
+
+
+ o Delivery-verify
+
+ The MTS performer should first make sure that it has received an
+ INVOKE.indication. Any other type of primitive shouldn't be
+ occurring at this point, and should be ignored.
+
+ If there's something wrong with the PDU or operation data, the MTS
+ performer should send back an error to the proper invoker:
+
+ 1. Send an ESROS Error Request, then go wait for a response (either
+ a confirmation or a failure indication). The response is sent
+ back on the same SAP type on which the event occurred.
+
+ 2. Keep track of the type of request that was issued.
+
+ If there isn't anything wrong with the PDU or operation data, then
+ the MTS performer has received a valid event from ESROS. This could
+ be any of the defined Submission and Delivery Protocol operations.
+
+5.1.2 Message-submission
+
+ 1. The Message-submission operation first checks to see which SAP
+ this Submit Request came in on.
+
+ 2. The request could have arrived as 2-Way SAP (see #3) or a 3-Way
+ SAP (see #7).
+
+ 3. If the event arrived on the 2-Way SAP, consider this a protocol
+ violation and ignore it.
+
+ 4. Wait for a response to the request. The response could be either
+ an ERROR.confirm (see #5) or a FAILURE.indication (see #6).
+
+ 5. The ERROR.request has been confirmed. The UA knows that the
+ submitted message wasn't sent. Since there was an error, there
+ is nothing more to do, so return.
+
+ 6. If the result to the ErrorRequest is a Failure.indication, it
+ can be assumed that either the UA has received nothing (the
+ ERROR.request PDU was lost), which means failure for the UA; or
+ that the 3-Way acknowledgment was lost, which means that the UA
+ has in fact received the ERROR.request PDU and knows about the
+ delivery failure. Either way, the message can be ignored. There
+ is nothing more to do, so return.
+
+ 7. If the event was received on the 3-Way SAP, then this is the
+ correct SAP on which to receive a Submit Request. Send back a
+ Result Request and keep track of the primitive which was issued.
+
+
+
+Banan Informational [Page 44]
+
+RFC 2524 EMSD February 1999
+
+
+ 8. Now wait for a response to our request. The response will be
+ either a Result.confirm (see #9) or a Failure.indication (see
+ #13).
+
+ 9. The RESULT.request has been confirmed.
+
+ 10. Submit the message to the RFC-822 mailer.
+
+ 11. Attempt, a number of times, to send the submitted message via
+ the RFC-822 mailer. If the send was successful, then return.
+
+ 12. If, after the maximum number of retries, the message was not
+ able to be sent, consider it a failure. Since the UA assumption
+ has been that submission was successful, but now it has not been
+ sent, a brand new message, a Non-Delivery message, must be
+ generated and delivered to the UA. When this is completed, then
+ return.
+
+ 13. A FAILURE.indication has occurred due to the previously issued
+ RESULT.request.
+
+ 14. A Submission Verification is issued to the UA to see if the
+ RESULT.request was received. There are three possible results
+ from sending the submission verification to the UA: Fail (see
+ #15), Send Message (see #16) or Drop Message (see #20).
+
+ 15. Fail -- The Submission-verify request didn't reach the UA, or
+ the Submission Verify response didn't get back. Ignore the
+ message and return.
+
+ 16. The Submission Verify operation succeeded, meaning that the UA
+ received the request, and responded with a message stating that
+ it wants the message to be sent.
+
+ 17. Attempt, a number of times, to send the submitted message via
+ the RFC-822 mailer.
+
+ 18. If the message was submitted to the RFC-822 mailer successfully,
+ then return. If, after the maximum number of retries, the
+ message was not able to send the message, consider it a failure.
+
+ 19. The UA already assumes that the Message-submission was
+ successful. Now since the submitted message has not been sent,
+ a brand new message, a Non-Delivery message, must be generated
+ and delivered to the UA. After this is accomplished, then
+ return.
+
+
+
+
+
+Banan Informational [Page 45]
+
+RFC 2524 EMSD February 1999
+
+
+ 20. The UA responded with a message stating that the message should
+ be dropped. This may occur if the UA never received the result
+ from the MTS, meaning that it never received the Message Id, and
+ had to therefore inform the user that the message couldn't be
+ submitted. This may also occur if the UA doesn't have the
+ record of the message being verified. It can be because the
+ message record has been aged and expired, or because the EMSD-UA
+ has not been able to keep the record of the received message
+ because of storage or memory limitations. There is nothing to
+ do, so return.
+
+5.1.3 Delivery-control
+
+ This operation can be processed immediately. After it is processed,
+ the appropriate result is returned.
+
+5.1.4 Delivery-verify
+
+ This operation occurs when the UA doesn't think that the MTS has
+ received the RESULT.indication from a previously delivered message.
+ The UA wants to make sure that the MTS knows it has been delivered.
+ The MTS will determine what it knows of the specified message, and
+ send back a result. This can be processed immediately, as it doesn't
+ need to deal with duplicate detection.
+
+5.1.5 MTS Invoker
+
+ The MTS invoker is responsible for processing the following
+ operations, received from ESROS:
+
+ o Message-delivery
+
+ o Submission-control
+
+ o Submission-verify
+
+
+ Submission-control
+
+ Process the Submission Control request.
+
+
+ Message-delivery
+
+ 1. Check the User Agent's profile to determine the SAP.
+
+ 2. Set the SAP to 3-Way.
+
+
+
+
+Banan Informational [Page 46]
+
+RFC 2524 EMSD February 1999
+
+
+ 3. Issue the INVOKE.request on the appropriate SAP, with duplication
+ detection enabled. Since a local error is possible on issuing
+ the INVOKE.request, a retry counter is needed.
+
+ 4. There are three possible events possible in result to the
+ INVOKE.request: an ERROR.indication (see #5), a
+ RESULT.indication (see #9) or a FAILURE.indication (see #10).
+
+ 5. An ERROR.indication was received, which means that the UA can't
+ accept the message right now.
+
+ 6. If the reason was one of a transient nature, wait for a while and
+ then send the Deliver Request again.
+
+ 7. If the reason was one of a permanent nature, send back a non-
+ delivery report to the originator.
+
+ 8. Since the error was one of a permanent nature, then the MTS must
+ send back a non-delivery report, then log the unsuccessful
+ delivery with error from UA and return.
+
+ 9. A RESULT.Indication was returned, which means that the Delivery
+ was successful. Send a delivery report to the originator if one
+ was requested and log successful delivery and return.
+
+ If the UA profile indicated that Complete mode was to be used,
+ keep track of the fact that this message has been successfully
+ delivered (as far as the MTS is concerned), so that if the UA
+ sends us a Delivery Verify operation, we know that we consider
+ the message to be delivered.
+
+ 10. A FAILURE.indication was returned, which means there was a
+ problem getting the Deliver Request to the UA, or in getting the
+ response back from the UA. In any case, a response was never
+ received, so the request timed out. Wait for a while, and then
+ send the Deliver Request again.
+
+ As long as a FAILURE.indication is returned and the number of
+ retries has not been exceeded, keep trying to verify the
+ delivery.
+
+
+ Submission-verify
+
+ The Submission-verify operation is always issued on the 2-Way SAP.
+ The response is awaited. If a response doesn't come, the request is
+ queued and attempted again later.
+
+
+
+
+Banan Informational [Page 47]
+
+RFC 2524 EMSD February 1999
+
+
+ 1. Issue the INVOKE.request on the 2-Way SAP, with duplication
+ detection disabled. Since a local error on issuing the invoke
+ request is possible, a retry counter is needed.
+
+ 2. An INVOKE.Request has been issued and a response has been
+ received. The response will be either a a RESULT.indication (see
+ #3) or a FAILURE.indication (see #4). There are no defined
+ errors to a Submission Verify operation, so an ERROR.indication
+ should not be occurring here.
+
+ 3. A RESULT.indication was received. Either ResponseSendMessage or
+ ResponseDropMessage, as specified in the PDU, will be returned.
+
+ 4. A FAILURE.indication was received, which means that there was a
+ problem getting the Submission Verify Request to the UA, or in
+ getting the response back from the UA. In any case, the response
+ was never received, so the request timed out. Wait for a while,
+ and then another attempt to send the Submission Verify request is
+ needed.
+
+
+ Non-Delivery Report
+
+ Issue an INVOKE.request containing a Submit operation with a content
+ type of Non-Delivery Report, to the UA. This operation is always
+ issued on the 2-Way SAP. The response is awaited. If a response
+ doesn't come, the request is queued and attempted again later.
+
+ 1. Create a Submit operation.
+
+ 2. Issue the INVOKE.request on the 2-Way SAP, with duplication
+ detection enabled. Since a local error on issuing the invoke
+ request is possible, a retry counter for is needed.
+
+ 3. A response to the INVOKE.Request has been received. The response
+ will be either a RESULT.indication (see #5), ERROR.indication
+ (see #4), or a FAILURE indication (see #7).
+
+ 4. An ERROR.indication was received, which means that the UA doesn't
+ know what to do with our non-delivery report. That's the UAs
+ problem, so just do nothing and return.
+
+ 5. A RESULT.indication was received, which means we delivered a
+ successful non-delivery report.
+
+ 6. The result is logged. Nothing more is needed, so return.
+
+
+
+
+
+Banan Informational [Page 48]
+
+RFC 2524 EMSD February 1999
+
+
+ 7. A FAILURE.indication was received, which means there was a
+ problem getting the Submit Request to the UA, or in getting the
+ response back from the UA. In any case, the response was never,
+ so the request timed out. Wait for a while, and then send the
+ Submission Verify request again.
+
+5.2 UA Behavior
+
+ The User Agent is event-driven.
+
+ If it received an event from ESROS, then it could be any of the
+ following types:
+
+ o Message deliver indication;
+
+ o Message deliver confirm and failure indication;
+
+ o Result and Error indication for a submit operation;
+
+ o Submission verify indication;
+
+ o Result and Error indication for a delivery verify operation;
+
+ o Result and Error indication for a delivery control operation;
+
+ o Submission control indication.
+
+ For an ESROS event responsibility is passed to the UA performer
+ (Section 5.2.1).
+
+ IF the UA received an event indicating that there's a message from
+ the user, for submission, then responsibility is passed to the UA
+ invoker (Section 5.2.2).
+
+5.2.1 UA Performer
+
+ The performer on the UA side is responsible for processing the
+ following operations:
+
+ o Message Delivery
+
+ o Submission Verification
+
+ o Submission Control
+
+
+
+
+
+
+
+Banan Informational [Page 49]
+
+RFC 2524 EMSD February 1999
+
+
+ Message-delivery
+
+ 1. A Message-delivery request is received.
+
+ 2. Check for the correctness of the PDU. If the PDU is bad the see
+ #3. If the PDU is good then see #8.
+
+ 3. Send an ESROS ERROR.request. If the request arrived on a 3-Way
+ SAP, use a 3-Way SAP for the result. If the request arrived on a
+ 2-Way SAP, use a 2-Way SAP for the result. Keep track of the
+ type of request that was issued.
+
+ 4. Wait for the ESROS event. The result could be an ERROR.confirm
+ (see #5) or a FAILURE.indication (see #7).
+
+ 5. The ESROS event was an ERROR.confirm
+
+ 6. Log the message as the Non-Delivery was confirmed by the MTS and
+ return.
+
+ 7. If the ESROS event was a FAILURE.indication, that means one of
+ two things has occurred:
+
+ A. The MTS has received nothing (the ERROR.request PDU was lost),
+ which means that the MTS doesn't know that the message
+ delivery has been rejected. In this case, the MTS will
+ eventually time out, and retransmit the message delivery
+ request.
+
+ B. The 3-Way acknowledgment was lost, which means that the MTS
+ has in fact received the ERROR.request PDU and knows about the
+ delivery failure.
+
+ Either way, the message can now be ignored.
+
+ 8. Send an ESROS RESULT.request. If the request arrived on a 3-Way
+ SAP, use a 3-Way SAP for the result. If the request arrived on a
+ 2-Way SAP, use a 2-Way SAP for the result. Keep track of the
+ type of request that was issued.
+
+ 9. Wait for the ESROS event. The result could be an RESULT.confirm
+ (see #10) or a FAILURE.indication (see #13).
+
+ 10. If the event is a RESULT.confirm, then the delivered message can
+ now be given to the user.
+
+ 11. Deliver the message to the user.
+
+
+
+
+Banan Informational [Page 50]
+
+RFC 2524 EMSD February 1999
+
+
+ 12. Log the message as Message Delivery Known to MTS.
+
+ 13. If the event is a FAILURE.indication, then, if the delivery was
+ on a 3-Way SAP, a Delivery Verification request to the MTS can
+ be issued to see if the MTS actually got the RSULT.request. If
+ the delivery was on a 2-Way SAP, then the message will delivered
+ to the user and if the MTS has not received the RESULT.request,
+ it will retransmit it later and the duplicate will be ignored.
+
+ 14. Deliver the message to the user. Since a FAILRUE.indication was
+ received in response to a RESULT.requst, it means that possible,
+ the MTS didn't receive the RESULT.request. The MTS could now
+ time out, and send another copy of the same message. Save the
+ message for duplication detection.
+
+ 15. Log the fact that the message was delivered, but that the MTS
+ might not be aware of it.
+
+ 16. If the UA supports Delivery Verification, and the Delivery
+ Request was sent on the 3-Way SAP, then see #17. If either of
+ these conditions are not true, then return.
+
+ 17. Send a Delivery-verify request to see if the MTS got the
+ RESULT.request.
+
+ There are three possible results from sending the delivery
+ verification to the MTS: Fail (see #18), ResponseNonDelivery
+ (see #20) or ResponseDelivery (see #23).
+
+ 18. Fail -- Delivery Verify request didn't reach the MTS, or the
+ Delivery Verify response didn't get back to the UA.
+
+ 19. Log this as delivering the message to the user, but the MTS
+ having possibly sent a Non-Delivery report to the originator
+ even though the UA did actually deliver the message to the user.
+ Then return.
+
+ 20. ResponseNonDelivery -- Verify Response indicates that the MTS
+ now knows (because of the Delivery Verify operation that the
+ message has been delivered to the user, but had not received our
+ RESULT.request nor a Delivery Verify operation in a timely
+ manner, and had already sent out a Non-Delivery report to the
+ originator.
+
+ 21. The MTS had not received, from the UA, in a timely manner, a
+ RESULT.indication indicating that the message had been delivered
+ to the user. The MTS has already sent a Non-Delivery report to
+
+
+
+
+Banan Informational [Page 51]
+
+RFC 2524 EMSD February 1999
+
+
+ the originator. The UA must let the user know about this. Log
+ the message as delivered to the user, but a Non-Delivery sent to
+ the originator.
+
+ 22. Since the UA received a response to the Verify operation, it
+ knows that the MTS knows about this message delivery, so the UA
+ also knows that it won't be receiving a duplicate of it. The UA
+ can now remove this message's Message Id from the list of
+ possible duplicates.
+
+ 23. ResponseDelivery -- Verify Response received from MTS.
+
+ 24. This means that the MTS knows (either because the MTS had
+ received the RESULT.request that was sent by the UA or because
+ the MTS has now received the UAs Delivery-verification message,
+ informing that the UA received the message for delivery to the
+ user. The MTS is (or was) able to send a Delivery report to the
+ originator if one was requested. Log it as such.
+
+ 25. Since the UA received a response to the Verify operation, it
+ knows that the MTS knows about this message delivery, so the UA
+ also knows that it won't be receiving a duplicate of it. The UA
+ can now remove this message's Message Id from the list of
+ possible duplicates and return.
+
+
+ Submission-verify
+
+ Process the Submission-verify request and return.
+
+
+ Submission-control
+
+ This operation can be processed immediately. After it is processed,
+ the appropriate result is returned.
+
+5.2.2 UA Invoker
+
+ The invoker on the UA side is responsible for processing the
+ following operations:
+
+ o Message-submission
+
+ o Delivery-control
+
+ o Delivery-verify
+
+
+
+
+
+Banan Informational [Page 52]
+
+RFC 2524 EMSD February 1999
+
+
+ Message-submission
+
+ General procedures for UA's Message-submission mirror that of MTS's
+ Message-delivery.
+
+
+ Delivery-control
+
+ 1. Issue the INVOKE.request on the 3-Way SAP, with duplication
+ detection enabled. Since the UA can get a local error on issuing
+ the invoke request, a retry counter is needed.
+
+ If we got a local failure in issuing the Invoke Request, wait a
+ while and then try again (up to the limit of the maximum number
+ of retries).
+
+ 2. The UA has issued an INVOKE.Request. Wait for a response from
+ ESROS. The response will be either a RESULT.indication (see #5),
+ ERROR.indication (see #3), or FAILURE.indication (see #7).
+
+ 3. A ERROR.indicaiton was received, meaning that the MTS told says
+ that it cannot accept the message.
+
+ 4. Log the MTS rejection and return
+
+ 5. A RESULT.indication was received, which means that the Submission
+ was successful.
+
+ 6. Log successful submission and return.
+
+ 7. a FAILURE.indication was received, meaning that there was a
+ problem getting the Submit Request to the MTS, or in getting the
+ response back from the MTS. In any case, the UA never received
+ the response, so the request timed out. Wait for a while, and
+ then send the Submit Request again.
+
+ 8. The UA has exceeded the maximum number of retries. Let the user
+ know, log the failure and return.
+
+
+ Delivery-verify
+
+ General procedures for UA's Delivery-verify mirror that of MTS's
+ Submission-verify.
+
+
+
+
+
+
+
+Banan Informational [Page 53]
+
+RFC 2524 EMSD February 1999
+
+
+6 EMSD FORMAT STANDARDS
+
+6.1 Format Standard Overview
+
+ 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 [3]. 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) [5].
+ Future revisions of this specification will use Packed Encoding Rules
+ (PER) [4].
+
+ The convention of (O) "OPTIONAL", (D) "DEFAULT", (C) "CONDITIONAL"
+ and (M) "MANDATORY" which express requirements for presence of
+ information is used in this section.
+
+6.2 Interpersonal Messages
+
+ An interpersonal message (IPM) consists of a heading and a body.
+
+ IPM ::= SEQUENCE
+
+ {
+
+ heading Heading,
+
+
+
+
+Banan Informational [Page 54]
+
+RFC 2524 EMSD February 1999
+
+
+ body Body OPTIONAL
+
+ };
+
+6.2.1 Heading fields
+
+ 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,
+
+
+
+
+Banan Informational [Page 55]
+
+RFC 2524 EMSD February 1999
+
+
+ -- 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
+
+
+
+Banan Informational [Page 56]
+
+RFC 2524 EMSD February 1999
+
+
+ [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.
+
+
+ Sender
+
+ This field is mandatory if the sender is different from the
+ originator.
+
+
+ Originator
+
+ The Originator heading field (O) identifies the IPM's originator.
+
+ Recipient-data
+
+
+ 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
+
+
+
+Banan Informational [Page 57]
+
+RFC 2524 EMSD February 1999
+
+
+ -- 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 }
+
+ };
+
+
+ recipient-address
+
+ 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.
+
+
+ per-recipient-flags
+
+ 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.
+
+
+ recipient-type-copy
+
+ This field is set if the recipient is on the Carbon Copy (CC) list.
+
+
+ recipient-type-blind-copy
+
+ 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.
+
+
+
+
+
+
+
+
+Banan Informational [Page 58]
+
+RFC 2524 EMSD February 1999
+
+
+ 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.
+
+
+ notification-request-rn
+
+ A receipt notification (rn) reports its originator's receipt, or his
+ expected and arranged future receipt, of an IPM.
+
+
+ notification-request-nrn
+
+ A non-receipt notification (nrn) reports its originator's failure to
+ receive, to accept, or his delay in receiving, an IPM.
+
+
+ notification-request-ipm-return
+
+ When this field is set, the contents of the message are returned
+ along with the notification.
+
+
+ report-request-non-delivery
+
+ 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.
+
+
+ report-request-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.
+
+
+ reply-requested
+
+ When set this field indicates that the originator requests that a
+ recipient send a message in reply to the message which carries the
+ request.
+
+
+
+
+Banan Informational [Page 59]
+
+RFC 2524 EMSD February 1999
+
+
+ per-message-Flags
+
+
+ Priority
+
+ 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.
+
+
+ Importance
+
+ 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.
+
+
+ auto-forwarded
+
+ The Auto-forwarded heading field (default is false) indicates whether
+ the IPM is the result of auto-forwarding. It is a Boolean value.
+
+
+ reply-to
+
+ User-specified recipient or recipients who are to receive replies to
+ this message.
+
+
+ replied-to IPM
+
+ 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.
+
+
+
+
+Banan Informational [Page 60]
+
+RFC 2524 EMSD February 1999
+
+
+ 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.
+
+
+ subject
+
+ The Subject heading field (O) identifies the subject of the IPM. It
+ corresponds to the "Subject:" field of RFC-822.
+
+
+ extensions
+
+ 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
+ };
+
+6.2.2 Body part types
+
+ 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.
+
+
+
+Banan Informational [Page 61]
+
+RFC 2524 EMSD February 1999
+
+
+ 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)
+
+7 ACKNOWLEDGMENTS
+
+ In the context of Limited Size Messaging (LSM) over CDPD and pACT
+ over Narrowband PCS, AT&T Wireless Services (AWS), funded work which
+ was relevant to the development of the EMSD protocols.
+
+8 SECURITY CONSIDERATIONS
+
+ This protocol supports simple authentication of the originator's
+ address by the EMSD-SA and simple authentication of EMSD-SA by EMSD-
+ UA.
+
+ Mainstream Internet mail security mechanisms can be used in
+ conjunction with the EMSD protocol.
+
+9 AUTHOR'S ADDRESS
+
+ Mohsen Banan
+ Neda Communications, Inc.
+ 17005 SE 31st Place
+ Bellevue, WA 98008
+
+ EMail: mohsen@neda.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Banan Informational [Page 62]
+
+RFC 2524 EMSD February 1999
+
+
+A EMSD-P ASN.1 MODULE
+
+ This section compiles in one place the complete ASN.1 Module for EM
+ Submission and Delivery Protocol.
+
+ EMSD-SubmissionAndDeliveryProtocol DEFINITIONS ::=
+
+ BEGIN
+
+ EXPORTS EMSDORAddress, AsciiPrintableString, ContentType,
+ DateTime, EMSDMessageId, EMSDORAddress, ProtocolVersionNumber;
+
+ -- Upper bounds
+
+ ub-recipients INTEGER ::= 256;
+ -- also defined in EMSD-InterpersonalMessaging1995
+ ub-reply-to INTEGER ::= 256;
+ -- also defined in EMSD-InterpersonalMessaging1995
+ ub-subject-field INTEGER ::= 128;
+ -- also defined in EMSD-InterpersonalMessaging1995
+ ub-password-length INTEGER ::= 16;
+ ub-content-length INTEGER ::= 65535;
+ -- also defined in EMSD-Probe
+ ub-content-types INTEGER ::= 128;
+ ub-message-id-length INTEGER ::= 127;
+ ub-total-number-of-segments INTEGER ::= 32;
+ ub-header-extensions INTEGER ::= 64;
+ -- also defined in EMSD-InterpersonalMessaging1995
+ ub-emsd-name-length INTEGER ::= 64;
+ ub-emsd-address-length INTEGER ::= 20;
+ ub-rfc822-name-length INTEGER ::= 127;
+ ub-mime-version-length INTEGER ::= 8;
+ -- also defined in EMSD-InterpersonalMessaging1995
+ ub-mime-content-type-length INTEGER ::= 127;
+ -- also defined in EMSD-InterpersonalMessaging1995
+ ub-mime-content-id-length INTEGER ::= 127;
+ -- also defined in EMSD-InterpersonalMessaging1995
+ ub-mime-content-description-length INTEGER ::= 127;
+ -- also defined in EMSD-InterpersonalMessaging1995
+ ub-mime-content-transfer-encoding INTEGER ::= 127;
+ -- also defined in EMSD-InterpersonalMessaging1995
+ ub-local-message-nu INTEGER ::= 4096;
+
+ ----------------------
+ -- SUBMIT Operation --
+ ----------------------
+
+ submit ES-OPERATION
+
+
+
+Banan Informational [Page 63]
+
+RFC 2524 EMSD February 1999
+
+
+ ARGUMENT SubmitArgument
+ RESULT SubmitResult
+ ERRORS
+ {
+ submissionControlViolated,
+ securityError,
+ resourceError,
+ protocolViolation,
+ messageError
+ } ::= 33;
+
+ SubmitArgument ::= SEQUENCE
+ {
+ -- Security features
+ security [0] IMPLICIT SecurityElement
+ OPTIONAL,
+
+ -- Segmentation features for efficient transport
+ segment-info SegmentInfo OPTIONAL,
+
+ -- Content type of the message
+ content-type ContentType,
+
+ --
+ -- THE CONTENT --
+ --
+
+ -- The submission content
+ content ANY DEFINED BY content-type
+
+ };
+
+ SubmitResult ::= SEQUENCE
+
+ {
+
+ -- Permanent identifier for this message.
+ -- Also contains the message submission time.
+ -- See comment regarding assignment of message
+ -- identifiers, at the definition of EMSDLocalMessageId.
+ message-id EMSDLocalMessageId
+ };
+
+ --------------------------------
+ -- Delivery Control Operation --
+ --------------------------------
+
+ deliveryControl ES-OPERATION
+
+
+
+Banan Informational [Page 64]
+
+RFC 2524 EMSD February 1999
+
+
+ ARGUMENT DeliveryControlArgument
+ RESULT DeliveryControlResult
+ ERRORS
+ {
+ securityError,
+ resourceError,
+ protocolViolation
+ } ::= 2;
+
+ DeliveryControlArgument ::= SEQUENCE
+ {
+ -- Request an addition of or removal of a set of restrictions
+ restrict [0] IMPLICIT Restrict DEFAULT update,
+
+ -- Which operations are to be placed in the restriction set
+ permissible-operations [1] IMPLICIT Operations OPTIONAL,
+
+ -- What maximum content length should be allowed
+ permissible-max-content-length
+ [2] IMPLICIT INTEGER
+ (0..ub-content-length) OPTIONAL,
+
+ -- What is the lowest priority message which may be delivered
+ permissible-lowest-priority
+ [3] IMPLICIT ENUMERATED
+ {
+ non-urgent (0),
+ normal (1),
+ urgent (2)
+ } OPTIONAL,
+
+ -- Security features
+ security [4] IMPLICIT SecurityElement
+ OPTIONAL,
+
+ -- User Feature selection
+ user-features [5] IMPLICIT OCTET STRING OPTIONAL
+ };
+
+ DeliveryControlResult ::= SEQUENCE
+ {
+ -- Operation types queued at the EMSD-SA due to existing
+ -- restrictions.
+ waiting-operations [0] IMPLICIT Operations DEFAULT { },
+
+
+ -- Types of messages queued at the EMSD-SA due to
+ -- existing restrictions
+
+
+
+Banan Informational [Page 65]
+
+RFC 2524 EMSD February 1999
+
+
+ waiting-messages [1] IMPLICIT WaitingMessages DEFAULT { },
+
+ -- Content Types of messages queued at the EMSD-SA
+ waiting-content-types SEQUENCE SIZE (0..ub-content-types) OF
+ ContentType DEFAULT { }
+ };
+
+ Restrict ::= ENUMERATED
+ {
+ update (1),
+ remove (2)
+ };
+
+ Operations ::= BIT STRING
+ {
+ submission (0),
+ delivery (1)
+ };
+
+
+ WaitingMessages ::= BIT STRING
+ {
+ long-content (0),
+ low-priority (1)
+ };
+
+ -- Delivery Verify Operation
+
+ deliveryVerify ES-OPERATION
+
+ ARGUMENT DeliveryVerifyArgument
+ RESULT DeliveryVerifyResult
+ ERRORS
+ {
+ verifyError,
+ resourceError,
+ protocolViolation
+ } ::= 5;
+
+ DeliveryVerifyArgument ::= SEQUENCE
+ {
+ -- Identifier of this message. This is the same identifier that
+ -- was provided to the originator in the Submission Result.
+ -- See comment regarding assignment of message identifiers,
+ -- at the definition of EMSDMessageId.
+ message-id EMSDMessageId
+ };
+
+
+
+
+Banan Informational [Page 66]
+
+RFC 2524 EMSD February 1999
+
+
+ DeliveryVerifyResult ::= SEQUENCE
+ {
+ status DeliveryStatus
+ };
+
+ DeliveryStatus ::= ENUMERATED
+ {
+ no-report-is-sent-out (1),
+ delivery-report-is-sent-out (2),
+ non-delivery-report-is-sent-out (3)
+ };
+
+ -----------------------
+ -- DELIVER Operation --
+ -----------------------
+
+ deliver ES-OPERATION
+ ARGUMENT DeliverArgument
+ RESULT NULL
+ ERRORS
+ {
+ deliveryControlViolated,
+ securityError,
+ resourceError,
+ protocolViolation,
+ messageError
+ } ::= 35;
+
+ DeliverArgument ::= SEQUENCE
+ {
+ -- Identifier of this message. This is the same identifier that
+ -- was provided to the originator in the Submission Result.
+ -- See comment regarding assignment of message identifiers,
+ -- at the definition of EMSDMessageId.
+ message-id EMSDMessageId,
+
+ -- Time the message was delivered to the recipient by EMSD-SA
+ message-delivery-time DateTime,
+
+ -- Time EMSD-SA originally took responsibility for processing
+ -- of this message. This field shall be omitted if the message-id
+ -- contains an EMSDLocalMessageId, because that field contains
+ -- the submission time within it.
+ message-submission-time [0] IMPLICIT DateTime OPTIONAL,
+
+ -- Security features
+ security [1] IMPLICIT SecurityElement OPTIONAL,
+
+
+
+
+Banan Informational [Page 67]
+
+RFC 2524 EMSD February 1999
+
+
+ -- SegContentTypementation features for efficient transport
+ segment-info SegmentInfo OPTIONAL,
+
+ -- The type of the content
+ content-type ContentType,
+
+ --
+ -- THE CONTENT --
+ --
+
+ -- The submitted (and now being delivered) content
+ content ANY DEFINED BY content-type
+
+ };
+
+ -- Submission Control Operation
+
+ submissionControl ES-OPERATION
+ ARGUMENT SubmissionControlArgument
+ RESULT SubmissionControlResult
+ ERRORS
+ {
+ securityError,
+ resourceError,
+ protocolViolation
+ } ::= 4;
+
+ SubmissionControlArgument ::= SEQUENCE
+ {
+ -- Request an addition of or removal of a set of restrictions
+ restrict [0] IMPLICIT Restrict DEFAULT update,
+
+ -- Which operations are to be placed in the restriction set
+ permissible-operations [1] IMPLICIT Operations OPTIONAL,
+
+ -- What maximum content length should be allowed
+ permissible-max-content-length
+ [2] IMPLICIT INTEGER
+ (0..ub-content-length) OPTIONAL,
+
+ -- Security features
+ security [3] IMPLICIT SecurityElement
+ OPTIONAL
+ };
+
+ SubmissionControlResult ::= SEQUENCE
+ {
+ -- Operation types queued at the EMSD-SA due to existing
+
+
+
+Banan Informational [Page 68]
+
+RFC 2524 EMSD February 1999
+
+
+ -- restrictions.
+ waiting-operations [0] IMPLICIT Operations DEFAULT { }
+
+ };
+
+ ----------------------------------
+ -- Submission Verify Operation --
+ ----------------------------------
+
+ submissionVerify ES-OPERATION
+
+ ARGUMENT SubmissionVerifyArgument
+ RESULT SubmissionVerifyResult
+ ERRORS
+ {
+ submissionVerifyError,
+ resourceError,
+ protocolViolation
+ } ::= 6;
+
+ SubmissionVerifyArgument ::= SEQUENCE
+ -- Identifier of this message. This is the same identifier that
+ -- was provided to the originator in the Submission Result.
+ -- See comment regarding assignment of message identifiers,
+ -- at the definition of EMSDMessageId.
+ {
+ message-id EMSDMessageId
+ };
+
+ SubmissionVerifyResult ::= SEQUENCE
+ {
+ status SubmissionStatus
+ };
+
+ SubmissionStatus::= ENUMERATED
+ {
+ send-message (1),
+ drop-message (2)
+ };
+
+ -- GetConfiguration Operation
+ -- To be fully defined later. This will possibly include,
+ -- but not be limited to:
+ -- get-local-time-zone
+ -- get-protocol-version
+ -- etc.
+
+ getConfiguration ES-OPERATION
+
+
+
+Banan Informational [Page 69]
+
+RFC 2524 EMSD February 1999
+
+
+ ARGUMENT NULL
+ RESULT NULL
+ ERRORS
+ {
+ resourceError,
+ protocolViolation
+ } ::= 7;
+
+ -- SetConfiguration Operation
+ -- To be fully defined later.
+
+ setConfiguration ES-OPERATION
+
+ ARGUMENT NULL
+ RESULT NULL
+ ERRORS
+ {
+ resourceError,
+ protocolViolation
+ } ::= 8;
+
+ -- Security --
+
+ SecurityElement ::= SEQUENCE
+
+ {
+ credentials Credentials,
+ contentIntegrityCheck ContentIntegrityCheck OPTIONAL
+ };
+
+ Credentials ::= CHOICE
+ {
+ simple [0] IMPLICIT SimpleCredentials
+ -- Strong Credentials are for future study
+ -- strong [1] IMPLICIT StrongCredentials
+ -- externalProcedure [2] EXTERNAL
+ };
+
+ SimpleCredentials ::= SEQUENCE
+
+ {
+ eMSDAddress EMSDAddress OPTIONAL,
+ password [0] IMPLICIT OCTET STRING
+ (SIZE (0..ub-password-length)) OPTIONAL
+ };
+
+ -- StrongCredentials ::= NULL
+ -- for now.
+
+
+
+Banan Informational [Page 70]
+
+RFC 2524 EMSD February 1999
+
+
+ -- ContentIntegrityCheck is a 16-bit checksum of content
+ ContentIntegrityCheck ::= INTEGER (0..65535);
+
+ SegmentInfo ::= CHOICE
+
+ {
+ first [APPLICATION 2] IMPLICIT FirstSegment,
+ other [APPLICATION 3] IMPLICIT OtherSegment
+ };
+
+ FirstSegment ::= SEQUENCE
+
+ {
+ sequence-id INTEGER,
+ number-of-segments INTEGER
+ -- number-of-segments must not exceed ub-total-number-of-segments
+
+ };
+
+ OtherSegment ::= SEQUENCE
+
+ {
+ sequence-id INTEGER,
+ segment-number INTEGER
+ };
+
+ -----------
+ -- Errors --
+ ------------
+
+ protocolVersionNotRecognized ERROR PARAMETER NULL ::= 1;
+
+ submissionControlViolated ERROR PARAMETER NULL ::= 2;
+
+ messageIdentifierInvalid ERROR PARAMETER NULL ::= 3;
+
+ securityError ERROR PARAMETER security-problem SecurityProblem ::= 4;
+
+ deliveryControlViolated ERROR PARAMETER NULL ::= 5;
+
+ resourceError ERROR PARAMETER NULL ::= 6;
+
+ protocolViolation ERROR PARAMETER NULL ::= 7;
+
+ messageError ERROR PARAMETER NULL ::= 8;
+
+ SecurityProblem ::= INTEGER (0..127);
+
+
+
+
+Banan Informational [Page 71]
+
+RFC 2524 EMSD February 1999
+
+
+ --
+ -- EXPORTED Definitions (for use by associated specifications) --
+ --
+
+ ContentType ::= INTEGER
+ {
+ -- Content type 0 is reserved and shall never be transmitted.
+ reserved (0),
+ -- Content types between 1 and 31 (inclusive) are for
+ -- internal-use only
+ probe (1), -- reserved
+ delivery-report (2), -- reserved
+
+ -- Content types between 32 and 63 (inclusive) are for
+ -- message types defined within this specifications.
+ emsd-interpersonal-messaging-1995 (32),
+ voice-messaging (33) -- reserved
+
+ -- Content types beyond and including 64 are for
+ -- bilaterally-agreed use between peers.
+ } (0..127);
+
+ -- If this message was originated as an RFC-822 message, then this
+ -- EMSDMessageId shall be the "Message-Id:" field from that message.
+ -- If this message was originated within the EMSD domain,
+ -- then this identifier shall be unique for the Message Center
+ -- generating this id.
+
+ EMSDMessageId ::= CHOICE
+ {
+ emsdLocalMessageId [APPLICATION 4] IMPLICIT
+ EMSDLocalMessageId,
+ rfc822MessageId [APPLICATION 5] IMPLICIT
+ AsciiPrintableString
+ (SIZE (0..ub-message-id-length))
+
+ };
+
+ EMSDLocalMessageId ::= SEQUENCE
+ {
+ submissionTime DateTime,
+ messageNumber INTEGER (0..ub-local-message-nu)
+ };
+
+ -- An Originator/Recipient Address in EMSD Environment
+
+ EMSDORAddress ::= CHOICE
+ {
+
+
+
+Banan Informational [Page 72]
+
+RFC 2524 EMSD February 1999
+
+
+ -- This is the local-format address
+ emsd-local-address-format EMSDAddress,
+
+
+ -- This is a globally-unique RFC-822 Address
+ rfc822DomainAddress AsciiPrintableString
+ };
+
+
+
+ EMSDAddress ::= SEQUENCE
+ {
+ emsd-address OCTET STRING
+ (SIZE (1..ub-emsd-address-length)),
+
+ -- emsd-address is a decimal integer in BCD (Binary Encoded Decimal)
+ -- format.
+ -- If it had an odd number of digits, it is padded with 0 on
+ -- the left.
+
+ emsd-name [0] IMPLICIT OCTET STRING
+ (SIZE (0..ub-emsd-name-length))
+ OPTIONAL
+ };
+
+ DateTime ::= INTEGER;
+
+ Iso8859String ::= GeneralString;
+
+ AsciiPrintableString ::= [ APPLICATION 0 ]
+ IMPLICIT Iso8859String (FROM
+
+ (" "|"!"|"#"|"$"|"%"|"&"|"'"|"("|")"|"*"|"+"|","|"-"|"."|"/"|
+ "0"|"1"|"2"|"3"|"4"|"5"|"6"|"7"|"8"|"9"|":"|";"|"<"|"="|">"|
+ "?"|"@"|"A"|"B"|"C"|"D"|"E"|"F"|"G"|"H"|"I"|"J"|"K"|"L"|"M"|
+ "N"|"O"|"P"|"Q"|"R"|"S"|"T"|"U"|"V"|"W"|"X"|"Y"|"Z"|"["|"]"|
+ "^"|"_"|"`"|"a"|"b"|"c"|"d"|"e"|"f"|"g"|"h"|"i"|"j"|"k"|"l"|
+ "m"|"n"|"o"|"p"|"q"|"r"|"s"|"t"|"u"|"v"|"w"|"x"|"y"|"z"|"{"|
+ "|"|"}"|"~"|"\"|""""));
+
+ ProtocolVersionNumber ::= [APPLICATION 1] SEQUENCE
+ {
+ version-major INTEGER,
+ version-minor [0] IMPLICIT INTEGER DEFAULT 0
+ }
+ END -- end of EMSD-SubmissionAndDeliveryProtocol
+
+
+
+
+
+Banan Informational [Page 73]
+
+RFC 2524 EMSD February 1999
+
+
+B EMSD-IPM ASN.1 MODULE
+
+ This section compiles in one place the complete ASN.1 Module for
+ EMSD-IPM.
+
+ EMSD-InterpersonalMessaging1995 DEFINITIONS ::=
+
+ BEGIN
+
+ IMPORTS EMSDORAddress, EMSDMessageId, AsciiPrintableString
+ FROM EMSD-SubmissionAndDeliveryProtocol;
+
+ ub-recipients INTEGER ::= 256;
+ ub-reply-to INTEGER ::= 256;
+ ub-subject-field INTEGER ::= 128;
+ ub-header-extensions INTEGER ::= 64;
+ ub-emsd-name-length INTEGER ::= 64;
+ ub-mime-version-length INTEGER ::= 8;
+ ub-mime-content-type-length INTEGER ::= 127;
+ ub-mime-content-id-length INTEGER ::= 127;
+ ub-mime-content-description-length INTEGER ::= 127;
+ ub-mime-content-transfer-encoding INTEGER ::= 127;
+
+ IPM ::= SEQUENCE
+
+ {
+ heading Heading,
+ body Body OPTIONAL
+ };
+
+ 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
+
+
+
+
+Banan Informational [Page 74]
+
+RFC 2524 EMSD February 1999
+
+
+ {
+ -- 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))
+
+
+
+Banan Informational [Page 75]
+
+RFC 2524 EMSD February 1999
+
+
+ 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
+ };
+
+ 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),
+
+
+
+Banan Informational [Page 76]
+
+RFC 2524 EMSD February 1999
+
+
+ -- 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 }
+
+ };
+
+ IPMSExtension ::= SEQUENCE
+ {
+ x-header-label AsciiPrintableString,
+ x-header-value AsciiPrintableString
+ };
+
+ 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)
+
+ END -- end of EMSD-InterpersonalMessaging1995
+
+
+
+
+
+
+Banan Informational [Page 77]
+
+RFC 2524 EMSD February 1999
+
+
+C RATIONALE FOR KEY DESIGN DECISIONS
+
+ This section summarizes the rationale behind key design decisions
+ that were made while developing the EMSD Protocols.
+
+C.1 Deviation From The SMTP Model
+
+ SMTP is the main mail transport mechanism throughout the Internet.
+ SMTP is widely deployed and well understood by many engineers who
+ specialize in Internet email. Because of these reasons, works based
+ on SMTP or derived from it have a higher likelyhood of being widely
+ deployed throughout the Internet.
+
+ However, SMTP is highly inefficient for transfer of short messages.
+ SMTP's inefficiency applies to both the number of transmissions and
+ also to the number of bytes transmitted.
+
+ Even when fully optimized with PIPELINING, SMTP is still quite
+ inefficient.
+
+ Submission of a short message with SMTP involves 15 transmissions.
+ Submission of a short message with SMTP and PIPELINING involves 9
+ transmissions. Submission of a short message with EMSD (EMSD-P and
+ ESRO) involves 3 transmissions (in typical cases).
+
+ The key requirement driving the design of EMSD is efficiency. It was
+ determined that the at least 3 fold gains in efficiency justifies the
+ deviation from the SMTP model.
+
+C.1.1 Comparison of SMTP and EMSD Efficiency
+
+ The table below illustrates the number of N-PDUs exchanged for
+ transfer of a short Internet email when using SMTP, SMTP and
+ PIPELINING, QMTP and EMSD. The names used for identifying the PDUs
+ are informal names.
+
+ SMTP SMTP + pipelining QMTP, QMQP, EMSD
+ ------- ----------------- ------------ -----------
+ client: SYN SYN SYN Submit.Req
+ server: SYN ok SYN ok SYN Submit.Resp
+ client: HELO EHLO message ack
+ server: ok PIPELINING accept close
+ client: MAIL MAIL RCPT DATA close
+ server: ok ok
+ client: RCPT message QUIT
+ server: ok accept ok close
+ client: DATA close
+ server: ok
+
+
+
+Banan Informational [Page 78]
+
+RFC 2524 EMSD February 1999
+
+
+ client: message
+ server: accept
+ client: QUIT
+ server: ok close
+ client: close
+
+C.2 Use of ESRO Instead of TCP
+
+ In order to provide the same level of reliability that the existing
+ email protocols provide for short messages, it is clear that a
+ reliable underlying service is needed. UDP [6], by itself, is
+ clearly not adequate.
+
+ Use of TCP however, involves three phases:
+
+ 1. Connection Establishment
+
+ 2. Data Transfer
+
+ 3. Disconnect
+
+ Reliable transfer of a short message using TCP at a minimum involves
+ 5 transmissions as it is the case with QMTP.
+
+ The key requirement driving the design of EMSD is Efficiency. It was
+ determined that elimination of the extra 2 transmissions that are an
+ inherent characteristic of TCP, justifies deviation from it.
+
+ ESRO protocol, as specified in (RFC-2188 [1]), provides reliable
+ connectionless remote operation services on top of UDP [6] with
+ minimum overhead. ESRO protocol supports segmentation and
+ reassembly, concatenation and separation.
+
+ Reliable transfer of a short message using ESRO involves 3
+ transmissions as it is the case with EMSD-P.
+
+C.3 Use Of Remote Procedure Call (RPC) Model
+
+ Many Internet protocols are "text-based". Few Internet protocols are
+ RPC based. Protocols designed around the "text-based" approach have
+ a better track record of acceptance throughout the Internet.
+
+ Considering that message submission and delivery in EMSD involve no
+ more than two data exchanges, the text-based model becomes the same
+ as an operation. Furthermore, the RPC model is the natural way of
+ using ESRO.
+
+
+
+
+
+Banan Informational [Page 79]
+
+RFC 2524 EMSD February 1999
+
+
+C.4 Use Of ASN.1
+
+ In order to minimize the number of bytes transferred, efficient
+ encoding mechanisms are needed.
+
+ Amongst today's encoding mechanisms, ASN.1 has the unique feature of
+ separating the abstract syntax from the encoding rules. By selecting
+ ASN.1 as the notation used for expressing EMSD's information objects,
+ EMSD has the flexibility of using the most efficient encoding rules
+ such as Packed Encoding Rules (PER) when they are available.
+
+ Efficient encoding can always be better performed when the syntax of
+ the information is known. In general, encoding and compression
+ techniques which use the knowledge of the syntax of the information
+ produce better results than those compression techniques that work on
+ arbitrary text.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Banan Informational [Page 80]
+
+RFC 2524 EMSD February 1999
+
+
+D FURTHER DEVELOPMENT
+
+ Beyond this documentation of existing implementations, further
+ development of EMSD protocol is anticipated.
+
+ The following deficiencies and areas of improvement are identified.
+
+ o Mapping of RFC-822 to EMSD-FS needs to be more explicit.
+
+ o Mapping of EMSD-FS to RFC-822 needs to be more explicit.
+
+ o Text of duplicate detection section needs more structure.
+
+ o SubmissionControl operation needs more informative description.
+
+ o Based on implementor's feedback the "EMSD PROCEDURE FOR
+ OPERATIONS" section needs to be adjusted or re-done.
+
+ o The EMSD protocol can be extended to also support transfer of
+ raw RFC-822 text-based messages in addition to EMSD-FS. This
+ would be a trade-off in favor of "ease of implementation"
+ against "efficiency of bytes transfered".
+
+ o Provide mechanisms to support fully automated initial
+ provisioning of mail-boxes.
+
+ Future development of the EMSD Protocol is anticipated to take place
+ at http://www.emsd.org/. Those interested in further development and
+ maintenance of this protocol are invited to join the various mailing
+ lists hosted at http://www.emsd.org/.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Banan Informational [Page 81]
+
+RFC 2524 EMSD February 1999
+
+
+E. References
+
+ [1] Banan, M., Cheng, J. and M. Taylor, "At&t/neda's efficient short
+ remote operations (ESRO) protocol specification version 1.2.",
+ RFC 2188, September 1997.
+
+ [2] Bradner, S., "Key words for use in RFCs to indicate requirement
+ levels", BCP 14, RFC 2119, March 1997.
+
+ [3] Crocker, D., "Standard for the format of ARPA internet text
+ messages", STD 11, RFC 822, August 1982.
+
+ [4] Information Processing --- Open Systems Interconnection ---
+ Specification of Packed Encoding Rules for Abstract Syntax
+ Notation One (ASN.1). International Organization for
+ Standardization and International Electrotechnical Committee.
+ International Standard 8825-2.
+
+ [5] Information Processing --- Open Systems Interconnection ---
+ Specification of Basic Encoding Rules for Abstract Syntax
+ Notation One (ASN.1). International Organization for
+ Standardization and International Electrotechnical Committee,
+ 1987. International Standard 8825.
+
+ [6] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August
+ 1980.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Banan Informational [Page 82]
+
+RFC 2524 EMSD February 1999
+
+
+F. Full Copyright Statement
+
+ Copyright (C) The Internet Society (1999). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Banan Informational [Page 83]
+