Network Working Group M. Banan
Request for Comments: 2524 Neda Communications, Inc.
Category: Informational February 1999
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
Neda的高效邮件提交和交付（EMSD）协议规范版本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.
版权所有（C）互联网协会（1999年）。版权所有。
IESG Note
IESG注释
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:
本文件中规定的协议适用于专用无线IP网络中的有限使用。但是，由于以下限制，它不适用于通用消息传输或通过公共互联网传输消息：
- 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.
EMSD是在ESRO[RFC2188]上分层的，它不提供拥塞控制。这使得机电工程署完全不适合在公共互联网上进行端到端的使用。只有在无线网络和公共互联网之间交换的所有机电工程署电子邮件将在两个地区之间传输机电工程署<->SMTP网关时，才应考虑在无线网络中使用机电工程署。
- 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.
该文档仅指定用于身份验证的明文密码。只有在使用足够强的加密来保护明文密码的情况下，才应通过无线网络使用EMSD。
- Lack of character set internationalization
- 缺少字符集国际化
EMSD has no provision for representation of characters outside of the ASCII repertoire or for language tags.
机电工程署并没有就ASCII指令表以外的字符表示或语言标记作出规定。
- Poorly defined gatewaying to and from Internet Mail
- 进出Internet邮件的定义不清的网关
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:
因此，IESG建议将EMSD部署限制在狭窄的环境中，即仅与对消息长度和格式（不超过几百字节ASCII文本）具有固有限制的设备通信，使用以下任一方式：
a. wireless links with adequate link-layer encryption and gatewayed to the public Internet, or
a. 具有足够链路层加密和网关连接至公共互联网的无线链路，或
b. a private IP network that is either very over-provisioned or has some means of congestion control.
b. 一种专用IP网络，其配置过度或具有某种拥塞控制手段。
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.
在不久的将来，IESG可能会成立一个工作组，以定义一个互联网标准跟踪协议，用于有效传输电子邮件，该协议将与现有互联网邮件协议高度兼容，并且将适合在全球互联网上运行，包括无线和有线链路。
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.
本文件规定了高效邮件提交和交付（EMSD）的协议和格式编码。EMSD是一种高度优化的消息传递协议，用于提交和传递互联网短邮件。机电工程署旨在配合现有的互联网邮件协议。
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.
本规范狭隘地关注于短消息的提交和传递，明确强调效率。机电工程署是专为使用无线网络（例如CDPD、无线IP、移动IP）而设计的。当邮件提交和交付的效率非常重要时，EMSD被设计为对主流互联网邮件协议的自然增强。因此，预计机电工程署将成为互联网邮件和基于IP的双向寻呼融合的初步基础。
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].
机电工程署对邮件提交和传递的可靠性要求与现有的电子邮件协议相同。EMSD协议在RFC-2188[1]中规定的高效短距离远程操作（ESRO）协议之上实现可靠的无连接邮件提交和交付服务。
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.
大多数现有的Internet邮件协议都没有效率。大多数现有的Internet邮件协议的设计都具有简单性和连续性，SMTP传统是两个主要要求。机电工程署的设计以效率为首要要求。
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.
EMSD在无线环境中的早期应用表现为基于IP的双向寻呼服务。该协议的效率也为大型集中运营的互联网邮件服务提供商带来了显著的好处。
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
1准备工作4 1.1互联网邮件提交和交付。4.1.2 EMSD与其他邮件协议的关系。5.1.3机电工程署的要求和目标。7.1.4机电工程署的预期用途。8.1.5本规范中所用术语的定义。9.1.6本规范中使用的惯例。9.1.7关于本规范。10 2高效邮件提交和交付概述10 3高效邮件提交和交付协议11 3.1较低层的使用。13.3.1.1 ESRO的使用。13.3.1.2 UDP的使用。13.3.1.3编码规则。13.3.1.4演示背景。14.3.2 EMSD-UA调用的操作。14.3.2.1提交。14.3.2.2交付控制。17.3.2.3交付验证。21.3.3 EMSD-SA调用的操作。23.3.3.1交付。23.3.3.2提交控制。25.3.3.3提交验证。28.3.4机电工程署通用信息对象。30.3.4.1证券要素。30.3.4.2消息分段和重新组装。30.3.4.3常见错误。33.3.4.4内容类型。35.3.4.5 EMSDMessageId。35.3.4.6 EMSD地址。36.3.4.7 EMSDAddress。36.3.4.8日期时间。36.3.4.9 AsciiPrintableString。37.3.4.10协议版本号。37.3.5提交和交付程序。38 4重复操作检测支持40
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
4.1重复操作检测支持概述。40.4.1.1操作值。40.4.1.2操作实例标识符。41 5 EMSD操作程序42 5.1 MTS行为。43.5.1.1 MTS执行者。43.5.1.2信息提交。44.5.1.3交付控制。46.5.1.4交付验证。46.5.1.5 MTS调用程序。46.5.2 UA行为。49.5.2.1 UA执行者。49.5.2.2 UA调用方。52 6机电工程署格式标准54 6.1格式标准概述。54.6.2人际信息。54.6.2.1标题字段。55.6.2.2车身部件类型。61 7致谢62 8安全考虑62 9作者地址62 A EMSD-P ASN.1模块63 B EMSD-IPM ASN.1模块74 C关键设计决策的理由78 C.1与SMTP模型的偏差。78 C.1.1 SMTP和EMSD效率的比较。78 C.2使用ESRO代替TCP。79 C.3远程过程调用（RPC）模型的使用。79 C.4 ASN.1的使用。80 D进一步开发81 E参考文献82 F完整版权声明83
1 PRELIMINARIES
1预备赛
Mail in the Internet was not a well-planned enterprise, but instead arose in more of an "organic" way.
互联网上的邮件不是一个精心策划的企业，而是以一种更“有机”的方式出现的。
This introductory section is not intended to be a reference model and concept vocabulary for mail in the Internet. Instead, it only provides the necessary preliminaries for the concepts and terms that are essential to this specification.
本介绍性章节不打算成为互联网上邮件的参考模型和概念词汇表。相反，它仅为本规范所必需的概念和术语提供必要的预备知识。
For the purposes of this specification, mail submission is the process of putting mail into the mail transfer system (MTS).
就本规范而言，邮件提交是将邮件放入邮件传输系统（MTS）的过程。
For the purposes of this specification, mail delivery is the process of the MTS putting mail into a user's final mail-box.
就本规范而言，邮件传递是MTS将邮件放入用户最终邮箱的过程。
Throughout the Internet, presently most of mail submission and delivery is done through SMTP.
在整个互联网上，目前大多数邮件提交和传递都是通过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.
SMTP被定义为消息*传输*协议，即通过将完成的（完整的）消息放入邮箱来路由（如果需要）和传递邮件的方法。最初，用户从终端连接到服务器，所有处理都发生在服务器上。现在，拆分MUA（邮件用户代理）模型很常见，MUA功能同时出现在用户自己的系统和服务器上。
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.
在splitmua模型中，通过POP和IMAP等协议访问服务器上的邮箱，向用户发送消息。在拆分MUA模型中，用户对其消息的访问是一种“消息拉取”范式，其中要求用户轮询其邮箱。目前不支持基于“消息推送”范式的正确消息传递。机电工程署的协议以效率为重点，解决了这一缺点。
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.
在拆分MUA模型中，消息提交通常通过SMTP完成。SMTP广泛用作消息*提交*协议。广泛使用SMTP进行提交是一种现实，无论这是好是坏。EMSD协议为消息提交提供了一种强调效率的替代机制。
Various Internet mail protocols facilitate accomplishment of various functions in mail processing.
各种Internet邮件协议有助于完成邮件处理中的各种功能。
Figure 1, categorizes the capabilities of SMTP, IMAP, POP and EMSD based on the following functions:
图1根据以下功能对SMTP、IMAP、POP和EMSD的功能进行了分类：
+------------------+------+-------+-----+------+
| 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 | | |
+------------------+------+-------+-----+------+
+------------------+------+-------+-----+------+
| 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
图1：消息传递协议与支持的功能
o Mail Submission
o 邮件提交
o Mail Delivery
o 邮递
o Mail Routing (Relay)
o 邮件路由（中继）
o Mail Retrieval
o 邮件检索
o Mail-box Access
o 邮箱访问
o Mail-box Synchronization
o 邮箱同步
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.
在图1中，每个框中“X”的数量表示特定协议支持特定功能的程度。
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.
图1清楚地显示了这些协议的组合可以用来相互补充，为用户提供丰富的功能。例如，对高度移动消息功能感兴趣的用户可以使用EMSD“提交和交付时间关键和重要的消息”，并使用IMAP全面访问其邮箱。
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
就邮件提交和发送短消息而言，无论从发送的数据包数量还是从发送的字节数量来看，机电工程署的效率都是SMTP的5倍。即使
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.
通过SMTP的管道和其他可能的优化，EMSD在传输的数据包数量和传输的字节数量方面的效率是SMTP的3倍。有各种效率研究将机电工程署与SMTP、POP和IMAP进行比较。有关SMTP和机电工程署效率比较的更多信息，请参见第C.1.1节。
The requirements and goals driving design of EMSD protocol are enumerated below.
下面列举了驱动EMSD协议设计的要求和目标。
1. Provide for submission of short mail messages with the same level of functionality (or higher) that the existing Internet mail protocols provide.
1. 提供与现有Internet邮件协议提供的功能级别相同（或更高）的短消息提交。
2. Provide for delivery of short mail messages with the same level of functionality (or higher) that the existing Internet mail protocols provide.
2. 提供与现有Internet邮件协议所提供的功能级别相同（或更高）的短邮件。
3. Function as an extension of the existing mainstream Internet mail.
3. 作为现有主流互联网邮件的扩展。
4. Minimize the number of transmissions.
4. 尽量减少传输次数。
5. Minimize the number of bytes transmitted.
5. 最小化传输的字节数。
6. Be quick: minimize latency of message submission and delivery.
6. 快速：最小化邮件提交和传递的延迟。
7. Provide the same level of reliability (or higher) that the existing email protocols provide.
7. 提供与现有电子邮件协议相同级别（或更高级别）的可靠性。
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.
8. 适应不同大小的消息：消息的大小可能决定系统如何处理消息，但系统必须适应它。
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).
9. 节能并尊重移动平台资源：包括内存和CPU级别，以及电池寿命（即轻客户端和重服务器）。
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.
10. 高度可扩展性：不同的用户需要不同的选项，因此解决方案不能要求每个功能都是每条消息的一部分。同样，将出现当前未被视为需求的用法。解决方案必须具有足够的可扩展性，以处理新出现的需求。
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.
11. 安全：提供与现有电子邮件协议相同的安全级别（或更高级别）。内容保密性、发起人/收件人身份验证和邮件完整性必须是用户可用的选项。
12. Easy to implement: Re-use existing technology as much as possible.
12. 易于实施：尽可能重复使用现有技术。
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.
机电工程署最初的用途预计主要是透过基于IP的无线网络提供双向传呼服务。
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 大多数无线网络将向基于IP的方向融合；
o that two-way paging is the main proven application in most wide-area wireless networks;
o 双向寻呼是大多数广域无线网络中经验证的主要应用；
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 双向寻呼行业和互联网电子邮件行业能够而且应该在一套充分满足效率要求的开放协议基础上融合；
o that existing Internet email protocols are not bandwidth efficient;
o 现有的互联网电子邮件协议没有带宽效率；
o that existing Internet email protocols do not properly support the "push" model of delivery of urgent messages,
o 现有的互联网电子邮件协议不支持紧急消息的“推送”模式，
the EMSD protocol is designed to facilitate the convergence of IP-based two-way paging and Internet email.
EMSD协议旨在促进基于IP的双向寻呼和Internet电子邮件的融合。
Mail submission and delivery take place at the edges of the network. More than one mail submission and delivery protocols which address requirements specific to a particular user's environment are likely to be developed. Such diversity on the edges of the network is
邮件提交和递送发生在网络边缘。可能会开发多个邮件提交和交付协议，以满足特定用户环境的特定需求。网络边缘的这种多样性是非常重要的
desirable and with the right protocols, this diversity does not adversely impact the integrity of the mail transfer system. EMSD is the initial basis for the mail submission and delivery protocol to be used when the user's environment demands efficiency.
通过适当的协议，这种多样性不会对邮件传输系统的完整性产生不利影响。当用户的环境要求效率时，EMSD是邮件提交和交付协议的初始基础。
The following informal definitions and acronyms are intended to help describe EMSD model described in this specification.
以下非正式定义和首字母缩略词旨在帮助描述本规范中描述的EMSD模型。
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)
高效邮件提交和交付协议（EMSD-P）：用于在EMSD-服务器代理（例如，消息中心）和EMSD-用户代理（例如，双向寻呼机）之间传输消息的协议，见图2。邮件传输代理（MTA）
Message Transfer Service (MTS)
消息传输服务（MTS）
Message Routing Service (MRS): Collection of MTAs responsible for mail routing. Message User Agent (MUA)
邮件路由服务（MRS）：负责邮件路由的MTA集合。消息用户代理（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.
高效邮件提交服务器代理（EMS-SA）：符合本协议规范的应用程序流程，接受来自EMS-UA的邮件并将其传输给收件人。
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.
高效邮件传递服务器代理（EMD-SA）：符合此协议规范并将邮件传递给EMD-UA的应用程序流程。高效邮件提交和交付服务器代理（EMSD-SA）：一个结合了EMS-SA和EMD-SA功能的应用程序流程。
Efficient Mail Submission User Agent (EMS-UA): An Application Process which conforms to this protocol specification and submits mail to EMS-SA.
高效邮件提交用户代理（EMS-UA）：符合本协议规范并向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.
高效邮件交付用户代理（EMD-UA）：符合本协议规范并接受来自EMD-SA的邮件交付的应用程序流程。高效的邮件提交和交付用户代理（EMSD-UA）：一种应用程序流程，它结合了EMS-UA和EMD-UA功能。
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this specification are to be interpreted as defined in [2].
本规范中的关键词“必须”、“不得”、“应该”、“不应该”和“可以”应按照[2]中的定义进行解释。
This specification uses the ES-OPERATION notation defined in Efficient Short Remote Operations (ESRO) protocols as specified in RFC-2188 [1].
本规范使用RFC-2188[1]中规定的高效短距离远程操作（ESRO）协议中定义的ES操作符号。
Operations and information objects are typically described using the ES-OPERATION and ASN.1 notations in the relevant sections of the specification.
操作和信息对象通常使用规范相关章节中的ES-OPERATION和ASN.1符号进行描述。
The complete machine verifiable ASN.1 modules are also compiled in one place in Appendix A and Appendix B.
完整的机器可验证ASN.1模块也在附录A和附录B中的一处进行了编译。
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.
本规范完全在IETF之外开发。它已经得到了IETF之外许多人的审查。已经从该协议的现有实现中学到了很多。许多缺陷和改进领域已经确定，并记录在本规范中。
This protocol specification is being submitted on October 23, 1998 for timely publication as an Informational RFC.
本协议规范于1998年10月23日提交，作为信息RFC及时发布。
Future development and enhancements to this protocol may take place inside of IETF.
本协议的未来开发和增强可能在IETF内部进行。
2 EFFICIENT MAIL SUBMISSION AND DELIVERY OVERVIEW
2高效的邮件提交和交付概述
This section offers a high level view of the Efficient Mail Submission and Delivery Protocol and Format Standards (EMSD-P&FS).
本节提供高效邮件提交和交付协议及格式标准（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.
EMSD-P&FS用于在EMSD-服务器代理（如消息中心）和EMSD-用户代理（如双向寻呼机）之间传输消息，见图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:
本规范定义了EMSD-用户代理（EMSD-UA）和EMSD-服务器代理（EMSD-SA）之间的协议。机电工程署-损益表由两个独立部分组成：
1. EMSD Format Standard (EMSD-FS).
1. EMSD格式标准（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
EMSD-FS是一种非文本形式的互联网邮件（RFC-822）压缩编码，有助于高效传输邮件。EMSD-FS与EMSD-P一起使用，但是
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.
不是RFC-822的一般替代品。EMSD-FS定义了一种人际短消息的表示方法。它定义了“内容”编码（标题+正文）。虽然EMSD-FS包含端到端信息，但其范围仅限于点对点。EMSD-FS依靠EMSD-P（见下文2）将内容传输给其收件人。
This is described in the section entitled EMSD Format Standards.
这在题为“机电工程署格式标准”的章节中进行了说明。
2. Efficient Mail Submission and Delivery Protocol (EMSD-P).
2. 高效邮件提交和交付协议（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.
EMSD-P负责将EMSD-FS消息（见上文1）包装在点对点信封中，并提交或交付。EMSD-P依靠RFC-2188[1]中规定的高效短距离远程操作服务（ESRO）传输点到点信封。EMSD-P的一些服务包括：消息发起人身份验证和可选的消息分段和重组。EMSD-P使用ESROS符号表示为抽象服务。这在题为“高效邮件提交和交付协议”的章节中进行了描述。
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.
重要的是要认识到，EMSD-P和EMSD-FS不是端到端的，而是侧重于点对点的消息传输。这两点是EMSD-SA和EMSD-UA。EMSD-P作为Internet邮件环境的组成部分，提供端到端（EMSD用户到任何其他邮件发送者或收件人）服务。
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.
图2说明了EMSD-P&FS如何定义特定EMSD-UA和特定EMSD-SA之间的通信。消息传输系统可包括多个EMSD sa。每个EMSD-SA可以有任意数量的与之通信的EMSD UAs。
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.
高效的邮件提交和传递服务使用高效的短远程操作服务（ESRO）。他们还使用重复操作检测支持功能，如标题为“重复操作检测支持功能”一节中所述。这些功能保证一次操作不超过一次。
3 EFFICIENT MAIL SUBMISSION AND DELIVERY PROTOCOL
3高效的邮件提交和交付协议
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.
EM提交是将消息从EMSD-UA传输到EMSD-SA的过程。EM交付是将消息从EMSD-SA传输到EMSD-UA的过程。
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.
“邮件提交服务”使EMSD-UA能够向EMSD-SA提交邮件，以便将其传输和交付给一个或多个收件人。消息提交服务包括提交操作（由EMSD-UA调用）和submitVerify操作（可能由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-SA能够向EMSD-UA传递消息。消息传递服务包括由EMSD-SA调用的传递操作，以及可能由EMSD-UA调用的deliverVerify操作。
EMSD-UA uses the following services:
EMSD-UA使用以下服务：
o Message-submission
o 邮件提交
+---------------------------------------------+
| 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 | | | | |
| | +---+ +---+ | +---+ |
| | | |
| +-------------------------+ |
| |
| |
+---------------------------------------------+
+---------------------------------------------+
| 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
图2：高效的邮件提交和交付协议
o Delivery-control (the deliveryControl operation).
o 交付控制（交付控制操作）。
EMSD-SA uses the following services:
EMSD-SA使用以下服务：
o Message-delivery
o 消息传递
o Submission-control (the submissionControl operation).
o 提交控制（submissionControl操作）。
This specification expresses information objects using ASN.1 [X.208].
本规范使用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.
本规范根据高效短距离远程操作（RFC-2188）[1]中规定的ESRO模型表示远程操作。本规范中使用了（RFC-2188）的ES操作符号来定义特定操作。
This specification uses the Duplicate Operation Detection Support functions as specified in Section 4.
本规范使用第4节规定的重复操作检测支持功能。
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.
按照（RFC-2188[1]）中的规定，ESRO协议在UDP[6]之上以最小的开销提供可靠的无连接远程操作服务。ESRO协议支持分段和重组、连接和分离。
ESRO Services (2-Way and 3-Way handshake) shall be used by the EMSD-P.
EMSD-P应使用ESRO服务（双向和三向握手）。
ESRO Service Access Point (SAP) selectors used by EMSD-P are enumerated in the protocol.
协议中列举了EMSD-P使用的ESRO服务接入点（SAP）选择器。
EMSD-P through ESRO MUST use UDP [6] port number 642 (esro-emsdp).
通过ESRO的EMSD-P必须使用UDP[6]端口号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.
请注意，EMSD-P的服务访问点（SAP）规范除了ESRO SAP选择器规范外，还包括UDP端口号规范。换句话说，EMSD-P使用ESRO SAPs并不排除其他协议使用相同的SAP选择器，这些协议使用的UDP端口不是端口642。ESRO的这种使用是ESRO的一个设计特点，它可以提高带宽效率，而不是可扩展性限制。
Use of Basic Encoding Rules (BER) [5] is mandatory for both EMSD Format Standards and EMSD Protocol.
EMSD格式标准和EMSD协议都必须使用基本编码规则（BER）[5]。
In order to minimize data transfer, the following restrictions shall be maintained in the formatting of EMSD PDUs:
为了尽量减少数据传输，在EMSD PDU的格式设置中应保持以下限制：
o Specifically, when ASN.1 Basic Encoding Rules are being used:
o 具体而言，当使用ASN.1基本编码规则时：
A. Only the "Definite" form of Length encoding MUST be used,
A.只能使用“确定”形式的长度编码，
B. The "Short" form of Length encoding MUST be used whenever possible (i.e. when the Length is less than 128), and
B.必须尽可能使用“短”形式的长度编码（即当长度小于128时），以及
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".
C.八位字节字符串和位字符串值，以及任何其他可能编码为“基本”或“构造”的本机ASN.1类型，必须始终编码为“基本”，且不得“构造”。
Parameter Encoding Type of "0" MUST be used in ESRO Protocol to identify Basic Encoding Rules for operation arguments.
ESRO协议中必须使用参数编码类型“0”，以标识操作参数的基本编码规则。
The following operations are invoked by EMSD-UA:
以下操作由EMSD-UA调用：
a. submit
a. 提交
b. deliveryControl
b. 交付控制
c. deliveryVerify
c. 发货确认
The submit operation uses the duplication detection functional unit while deliveryControl and deliveryVerify don't use the duplication detection.
提交操作使用重复检测功能单元，而deliveryControl和deliveryVerify不使用重复检测。
The complete definition of these operations follows.
这些操作的完整定义如下。
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.
“提交电子操作”使EMSD-UA能够向EMSD-SA提交邮件，以便将其传输和传递给一个或多个收件人。
submit ES-OPERATION
提交电子商务操作
ARGUMENT SubmitArgument
RESULT SubmitResult
ERRORS
{
submissionControlViolated,
securityError,
resourceError,
protocolViolation,
messageError
} ::= 33;
ARGUMENT SubmitArgument
RESULT SubmitResult
ERRORS
{
submissionControlViolated,
securityError,
resourceError,
protocolViolation,
messageError
} ::= 33;
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).
ES-OPERATION的成功完成意味着机电工程署SA已经接受了信息的责任（但并不意味着它已经将信息交付给了预期的接收者）。
The disruption of the ES-OPERATION by an error signifies that the EMSD-SA cannot assume responsibility for the message.
错误导致ES-OPERATION中断表示EMSD-SA无法对该信息承担责任。
Arguments
论据
This operation's arguments are:
此操作的参数为：
SubmitArgument ::= SEQUENCE
{
-- Security features
security [0] IMPLICIT SecurityElement OPTIONAL,
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,
--消息内容类型ContentType的内容类型，
-- -- THE CONTENT -- --
----内容----
-- The submission content content ANY DEFINED BY content-type };
--提交内容由内容类型}定义；
The fields are:
这些字段是：
Security
安全
See Section 3.4.1, "SecurityElements".
见第3.4.1节“安全要素”。
Segment-info
段信息
See Section 3.4.2, "Message Segmentation and Reassembly".
见第3.4.2节“消息分段和重新组装”。
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
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.
{
-- 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
消息id EMSDLocalMessageId
};
};
The fields are:
这些字段是：
Message-id
消息id
This result contains an EMSD-SA-identifier that uniquely and unambiguously identifies the message-submission. It shall be generated by the EMSD-SA.
此结果包含一个EMSD SA标识符，该标识符唯一且明确地标识消息提交。它应由EMSD-SA生成。
Errors
错误
See Section 3.4.3.
见第3.4.3节。
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使EMSD-UA能够临时限制EMSD-SA可以调用的操作，以及EMSD-SA可以通过消息传递ES-OPERATION传递给EMSD-UA的消息。
deliveryControl ES-OPERATION
ARGUMENT DeliveryControlArgument
RESULT DeliveryControlResult
ERRORS
{
securityError,
resourceError,
protocolViolation
} ::= 2;
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.
EMSD-SA应保留当前暂停的ES操作和消息，直到稍后时间，而不是放弃。
The successful completion of the ES-OPERATION signifies that the specified controls are now in force.
ES-操作的成功完成意味着指定的控制现在生效。
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.
ES-OPERATION返回一个指示，指示如果没有现行控制措施，EMSD-SA将调用的任何ES-OPERATION，或EMSD-SA将传递的任何消息类型。
Arguments
论据
This operation's arguments are:
此操作的参数为：
DeliveryControlArgument ::= SEQUENCE
{
-- Request an addition of or removal of a set of restrictions
DeliveryControlArgument ::= SEQUENCE
{
-- Request an addition of or removal of a set of restrictions
restrict [0] IMPLICIT Restrict DEFAULT update,
限制[0]隐式限制默认更新，
-- Which operations are to be placed in the restriction set permissible-operations [1] IMPLICIT Operations OPTIONAL,
--将哪些操作置于限制集中允许操作[1]隐式操作可选，
-- What maximum content length should be allowed permissible-max-content-length
--允许的最大内容长度是多少？允许的最大内容长度是多少
[2] IMPLICIT INTEGER (0..ub-content-length) OPTIONAL,
[2] 隐式整数（0..ub内容长度）可选，
-- What is the lowest priority message which may be delivered permissible-lowest-priority
--可传递的最低优先级消息是什么
[3] IMPLICIT ENUMERATED { non-urgent (0), normal (1), urgent (2) } OPTIONAL,
[3] 隐式枚举{非紧急（0）、正常（1）、紧急（2）}可选，
-- Security features security [4] IMPLICIT SecurityElement OPTIONAL,
--安全功能安全[4]隐式安全元素可选，
-- User Feature selection user-features [5] IMPLICIT OCTET STRING OPTIONAL };
--用户特征选择用户特征[5]隐式八位字节字符串可选}；
Restrict
限制
This argument indicates whether the controls on ES-OPERATIONS are to be updated or removed. It may be generated by the EMSD-UA.
此参数指示是更新还是删除ES-OPERATIONS上的控件。它可能由EMSD-UA生成。
This argument may have one of the following values:
此参数可能具有以下值之一：
o update: The other arguments update the prevailing controls;
o 更新：其他参数更新当前控件；
o remove: All temporary controls are to be removed
o 移除：移除所有临时控制装置
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.
此参数表示EMSD-SA可在EMSD-UA上调用的ES-OPERATIONS。它可能由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 消息传递：EMSD-SA可以/不可以调用传递ES-OPERATIONS；和
o Other ES-OPERATIONS are not subject to controls, and may be invoked at any time.
o 其他电子商务操作不受控制，可随时调用。
In the absence of this argument, the ES-OPERATIONS that the EMSD-SA may invoke on the EMSD-UA are unchanged.
在没有此参数的情况下，EMSD-SA可在EMSD-UA上调用的ES-OPERATIONS保持不变。
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.
此参数包含EMSD-SA应通过deliver ES-OPERATIONS发送给EMSD-UA的最长内容消息的内容长度（以八位字节为单位）。它可能由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.
在没有此参数的情况下，EMSD-SA可以传递给EMSD-UA的消息的允许最大内容长度不变。
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.
此参数包含EMSD-SA应通过deliver ES-OPERATIONS传送给EMSD-UA的最低优先级消息的优先级。它可能由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.
此参数可能具有submit ES-OPERATIONS优先级参数的以下值之一：正常、非紧急或紧急。
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.
在没有此论点的情况下，EMSD-SA应向EMSD-UA发送的最低优先级消息的优先级不变。
Security
安全
See Section 3.4.1, "SecurityElements".
见第3.4.1节“安全要素”。
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.
此参数包含允许EMSD-UA向MTS传递用户能够支持的功能集的信息。此参数将在定义setConfiguration和getConfiguration操作时定义。
Results
后果
DeliveryControlResult ::= SEQUENCE
{
-- Operation types queued at the EMSD-SA due to existing
-- restrictions.
waiting-operations [0] IMPLICIT Operations DEFAULT { },
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
waiting-messages [1] IMPLICIT WaitingMessages
DEFAULT { },
-- 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 { }
--以ContentType默认值{}的EMSD-SA等待内容类型序列大小（0..ub内容类型）排队的消息的内容类型
};
};
Restrict ::= ENUMERATED
{
update (1),
remove (2)
};
Restrict ::= ENUMERATED
{
update (1),
remove (2)
};
Operations ::= BIT STRING
{
submission (0),
delivery (1)
};
Operations ::= BIT STRING
{
submission (0),
delivery (1)
};
WaitingMessages ::= BIT STRING
{
long-content (0),
low-priority (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.
该结果表明，由EMSD-SA持有的ES-OPERATIONS，如果没有现行控制措施，EMSD-SA将在EMSD-UA上调用。它可能由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.
o 消息传递：EMSD-SA持有/未持有消息，如果没有现行控制措施，将在EMSD-UA上调用传递ES-OPERATIONS。
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.
如果没有这一结果，可以假定，由于现行控制措施，EMSD-SA没有保存任何要传递的消息。
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.
该结果表明了EMSD-SA持有的要交付给EMSD-UA的消息类型，如果不是针对现行控制，则将通过交付ES-OPERATIONS进行交付。它可能由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 长内容：EMSD-SA持有的发送给EMSD-UA的消息超过了当前有效的允许最大内容长度控制；
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;
o 低优先级：EMSD-SA持有的信息交付给EMSD-UA的优先级低于当前有效的允许最低优先级控制；
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.
在没有该结果的情况下，可以假设由于当前有效的允许最大内容长度、允许最低优先级或允许安全上下文控制，EMSD-SA没有保存任何消息以交付给EMSD-UA。
Errors
错误
See Section 3.4.3.
见第3.4.3节。
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-OPERATIONS使EMSD-UA能够在接收到故障时验证消息的传递。delivery ES-OPERATIONS指示。
deliveryVerify ES-OPERATION
交付验证ES-OPERATION
ARGUMENT DeliveryVerifyArgument
RESULT DeliveryVerifyResult
ERRORS
{
verifyError,
resourceError,
protocolViolation
} ::= 5;
ARGUMENT DeliveryVerifyArgument
RESULT DeliveryVerifyResult
ERRORS
{
verifyError,
resourceError,
protocolViolation
} ::= 5;
The duplicate operation detection is not required for this operation.
此操作不需要重复操作检测。
Arguments
论据
This operation's arguments are:
此操作的参数为：
DeliveryVerifyArgument ::= SEQUENCE
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
};
{
-- 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
消息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.
此参数包含一个EMSD SA标识符，用于将消息与所有其他消息区分开来。它应由EMSD-SA生成，并应具有与提交消息时提供给消息发起人的消息提交标识符相同的值。
Results
后果
DeliveryVerifyResult ::= SEQUENCE
{
status DeliveryStatus
};
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)
};
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).
该结果表明，EMSD-SA已收到交付验证，且未发送任何报告（可能是因为未请求该报告，或者是因为EMSD-SA存在问题，无法发送该报告）。
Delivery-report-is-sent-out
发货报告已发出
This result indicates that EMSD-SA has received the delivery verify
该结果表明，EMSD-SA已收到交付验证
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.
该结果表明，EMSD-SA已收到交付验证，但已发送未交付报告。这在正常情况下不应发生，但EMSD-SA端错误的用户配置文件可能导致此结果。
Errors
错误
See Section 3.4.3.
见第3.4.3节。
This section defines the operations invoked by the EMSD-SA:
本节定义了EMSD-SA调用的操作：
a. deliver;
a. 传送
b. submissionControl;
b. 提交控制；
c. submissionVerify.
c. 提交验证。
The deliver operation uses 3-Way handshake service of ESROS. This operation always uses the duplication detection functional unit.
交付操作使用ESROS的三方握手服务。此操作始终使用重复检测功能单元。
The submissionControl and submissionVerify operations use 2-Way handshake service of ESROS without duplication detection.
submissionControl和submissionVerify操作使用ESRO的双向握手服务，无需重复检测。
The deliver ES-OPERATIONS enables the EMSD-SA to deliver a message to an EMSD-UA.
deliver ES-OPERATIONS使EMSD-SA能够向EMSD-UA发送消息。
deliver ES-OPERATION
实施电子商务
ARGUMENT DeliverArgument
RESULT NULL
ERRORS
{
deliveryControlViolated,
securityError,
resourceError,
protocolViolation,
messageError
} ::= 35;
ARGUMENT DeliverArgument
RESULT NULL
ERRORS
{
deliveryControlViolated,
securityError,
resourceError,
protocolViolation,
messageError
} ::= 35;
The EMSD-UA MUST not refuse performing the deliver ES-OPERATION unless the delivery would violate the deliveryControl restrictions then in force.
除非交付违反当时生效的交付控制限制，否则EMSD-UA不得拒绝执行交付ES操作。
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,
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,
--通过EMSD-SA消息传递时间日期时间将消息传递给收件人的时间，
-- 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,
-- 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,
--安全功能安全[1]隐式安全元素可选，
-- SegContentTypementation features for efficient transport segment-info SegmentInfo OPTIONAL,
--SegContentTypementation功能用于高效传输段信息SegmentInfo可选，
-- The type of the content content-type ContentType,
--内容类型ContentType的类型，
-- -- THE CONTENT -- --
----内容----
-- The submitted (and now being delivered) content content ANY DEFINED BY content-type };
--已提交（现在正在交付）的内容由内容类型}定义；
message-id
消息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.
此参数包含一个EMSD SA标识符，用于将消息与所有其他消息区分开来。当在EMSD内时，它必须由EMSD-SA生成，并且必须具有与提交消息时提供给消息发起人的消息提交标识符相同的值。
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.
此参数包含传递发生的时间以及EMSD-SA放弃消息责任的时间。它应由EMSD-SA生成。
Results
后果
This operation returns an empty result as indication of success.
此操作返回一个空结果作为成功的指示。
Errors
错误
See Section 3.4.3.
见第3.4.3节。
submissionControl ES-OPERATION
ARGUMENT SubmissionControlArgument
RESULT SubmissionControlResult
ERRORS
{
securityError,
resourceError,
protocolViolation
} ::= 4;
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.
submissionControl ES-OPERATIONS使EMSD-SA能够临时限制EMSD-UA可以调用的操作，以及EMSD-UA可以通过submit ES-OPERATIONS提交给EMSD-SA的消息。
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.
EMSD-UA应保留当前暂停的ES-OPERATIONS和消息，直到稍后时间，而不是放弃。
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.
ES-操作的成功完成意味着指定的控制现在生效。这些控制取代以前生效的任何控制，并保持有效，直到关联被释放或EMSD-SA重新调用Submissions-OPERATIONS控制。
The ES-OPERATIONS returns an indication of any ES-OPERATIONS that the EMSD-UA would invoke were it not for the prevailing controls.
ES-OPERATIONS返回一个指示，表明如果没有现行控制措施，EMSD-UA将调用任何ES-OPERATIONS。
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,
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,
--将哪些操作置于限制集中允许操作[1]隐式操作可选，
-- What maximum content length should be allowed permissible-max-content-length [2] IMPLICIT INTEGER (0..ub-content-length) OPTIONAL,
--应允许的最大内容长度允许的最大内容长度[2]隐式整数（0..ub content length）可选，
-- Security features security [3] IMPLICIT SecurityElement OPTIONAL };
--安全特性安全[3]隐式安全元素可选}；
Restrict
限制
This argument indicates whether the controls on ES-OPERATIONS are to be updated or removed. It may be generated by the EMSD-SA.
此参数指示是更新还是删除ES-OPERATIONS上的控件。它可能由EMSD-SA生成。
This argument may have one of the following values:
此参数可能具有以下值之一：
o update: The other arguments update the prevailing controls;
o 更新：其他参数更新当前控件；
o remove: All temporary controls are to be removed
o 移除：移除所有临时控制装置
In the absence of this argument, the default update shall be assumed.
如果没有此参数，则应假定默认更新。
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.
此参数表示EMSD-UA可在EMSD-SA上调用的ES-OPERATIONS。它可能由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 提交：EMSD-UA可以/不可以调用提交电子操作；和
o Other ES-OPERATIONS are not subject to controls, and may be invoked at any time.
o 其他电子商务操作不受控制，可随时调用。
In the absence of this argument, the ES-OPERATIONS that the EMSD-UA may invoke on the EMSD-SA are unchanged.
在没有此参数的情况下，EMSD-UA可在EMSD-SA上调用的ES-OPERATIONS保持不变。
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.
此参数包含EMSD-UA应通过submit ES-OPERATIONS提交给EMSD-SA的最长内容消息的内容长度（以八位字节为单位）。它可能由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.
在没有此参数的情况下，EMSD-UA可能提交给EMSD-SA的消息的允许最大内容长度不变。
Security
安全
See Section 3.4.1, "SecurityElements".
见第3.4.1节“安全要素”。
Results
后果
SubmissionControlResult ::= SEQUENCE
{
-- Operation types queued at the EMSD-SA due to existing
-- restrictions.
waiting-operations [0] IMPLICIT Operations DEFAULT { }
SubmissionControlResult ::= SEQUENCE
{
-- Operation types queued at the EMSD-SA due to existing
-- restrictions.
waiting-operations [0] IMPLICIT Operations DEFAULT { }
};
};
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.
这一结果表明，机电工程署行动单位正在进行电子安全操作，如果没有现行控制措施，机电工程署行动单位将调用。它可能由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.
o 提交：EMSD-UA保存/未保存消息，如果未针对现行控制，则将调用提交电子操作。
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.
在没有该结果的情况下，可以假设由于现行控制措施，EMSD-UA没有保存任何要提交的消息。
Errors
错误
See Section 3.4.3.
见第3.4.3节。
The submissionVerify ES-OPERATIONS enables the EMSD-SA to verify if the EMSD-UA has received the result of its submission.
submissionVerify-OPERATIONS使EMSD-SA能够验证EMSD-UA是否已收到其提交的结果。
submissionVerify ES-OPERATION
提交验证操作
ARGUMENT SubmissionVerifyArgument
RESULT SubmissionVerifyResult
ERRORS
{
submissionVerifyError,
resourceError,
protocolViolation
} ::= 6;
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
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
};
-- 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
消息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.
此参数包含一个EMSD SA标识符，用于将消息与所有其他消息区分开来。它应由EMSD-SA生成，并应具有与提交消息时提供给消息发起人的消息提交标识符相同的值。
Results
后果
SubmissionVerifyResult ::= SEQUENCE
{
status SubmissionStatus
};
SubmissionVerifyResult ::= SEQUENCE
{
status SubmissionStatus
};
SubmissionStatus::= ENUMERATED
{
send-message (1),
drop-message (2)
};
SubmissionStatus::= ENUMERATED
{
send-message (1),
drop-message (2)
};
Send-message
发送消息
This result indicates that EMSD-SA is supposed to send the message out.
该结果表明，EMSD-SA应该发送该消息。
Drop-message
投递信息
This result indicates that EMSD-SA is supposed to drop the message.
该结果表明，EMSD-SA应该删除该消息。
Errors
错误
See Section 3.4.3.
见第3.4.3节。
SecurityElement ::= SEQUENCE
SecurityElement ::= SEQUENCE
{
credentials Credentials,
contentIntegrityCheck ContentIntegrityCheck OPTIONAL
};
{
credentials Credentials,
contentIntegrityCheck ContentIntegrityCheck OPTIONAL
};
Credentials ::= CHOICE
{
simple [0] IMPLICIT SimpleCredentials
Credentials ::= CHOICE
{
simple [0] IMPLICIT SimpleCredentials
-- Strong Credentials are for future study
-- strong [1] IMPLICIT StrongCredentials
-- externalProcedure [2] EXTERNAL
};
-- 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
};
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);
-- StrongCredentials ::= NULL
-- for now.
-- ContentIntegrityCheck is a 16-bit checksum of content
ContentIntegrityCheck ::= INTEGER (0..65535);
Small messages can benefit from the efficiencies of connectionless feature of ESROS (See Efficient Short Remote Operations, RFC-2188 [1]).
小消息可以从ESRO的无连接功能的效率中获益（参见高效短远程操作，RFC-2188[1]）。
Very large messages are transferred using protocols (e.g., SMTP) that rely on Connection Oriented Transport Service (e.g., TCP).
使用依赖于面向连接的传输服务（例如TCP）的协议（例如SMTP）传输非常大的消息。
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,
如果消息太大，无法装入单个无连接PDU，但又不足以证明建立连接的开销，则在使用ESROS的无连接服务时，对消息进行分段和重新组装可能更有效。如果底层远程操作服务能够通过无连接（CL）服务进行有效的分段/重组，
then use of the segmenting/reassembly mechanism introduced in this section is not necessary. This feature is accommodated in this layer by:
因此，无需使用本节介绍的分段/重新组装机制。此功能通过以下方式在该层中实现：
SegmentInfo ::= CHOICE
SegmentInfo ::= CHOICE
{
first [APPLICATION 2] IMPLICIT FirstSegment,
other [APPLICATION 3] IMPLICIT OtherSegment
};
{
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
};
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
};
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.
消息的发送者负责将消息内容分段为适合CL PDU的分段。分段内容以消息段序列的形式发送，每个消息段携带一段内容。序列Id是存在于所有消息段中的唯一标识符。除序列标识符外，第一个消息段还指定了段的总数（段数）。其他消息段具有段序列号（段编号）。接收方负责排序（基于段号）和重新组装整个消息。
Segmenting over the Connectionless ESRO Service
通过无连接ESRO服务进行分段
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.
消息的发送者将原始消息映射为消息段的有序序列。该序列不得被同一ESROS关联上的其他消息中断。
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.
发送方应为序列中的所有报文段分配一个序列标识符。在传输完整的消息序列后，发送方应将序列标识符增加1。
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).
第一个消息段指定段的总数。序列中除第一条以外的所有消息段应从1开始按顺序编号（第一条消息段的隐式段号为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.
通过发布消息提交或消息交付ES-OPERATIONS来传输每个消息段。分段报文的所有报文段均由相同的序列id标识。对于给定报文，接收方不应对报文段的到达顺序施加任何限制。
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.
对于无连接传输，ESRO不要求任何消息段内容具有允许的最大长度；但是，从单个消息中导出的段数不能超过ub总数。
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 重新组装计时器到期（见第3.4.3节）。
o Receipt of a message-segment with different sequence identifier.
o 接收具有不同序列标识符的消息段。
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.
当发送方收到某个报文段的故障指示（与resourceError相反）时，应重新传输整个报文。
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
接收器忽略接收到的消息段的故障指示，仅收集消息段以完成消息。但是，它会为分段消息保留一个故障状态，该状态表示消息的任何分段是否已收到故障指示。当接收器成功组装整个分段消息时，如果消息的状态显示任何消息段出现故障指示，则通过验证操作验证消息。仅基于最后一个消息段调用验证操作是不够的，因为发送方可能会发送
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).
接收方使用错误代码ResourceError（参见第3.4.3节）请求重新传输单个段，并使用错误代码MessageError（参见第3.4.3节）请求重新传输所有段（整个消息）。
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.
重新组装计时器的值是根据网络特性和段数定义的。这就要求必须在该时限内完成单个报文所有报文段的传输。
protocolVersionNotRecognized ERROR PARAMETER NULL ::= 1;
protocolVersionNotRecognized ERROR PARAMETER NULL ::= 1;
submissionControlViolated ERROR PARAMETER NULL ::= 2;
submissionControlViolated ERROR PARAMETER NULL ::= 2;
messageIdentifierInvalid ERROR PARAMETER NULL ::= 3;
messageIdentifierInvalid ERROR PARAMETER NULL ::= 3;
securityError ERROR PARAMETER security-problem SecurityProblem ::= 4;
securityError ERROR PARAMETER security-problem SecurityProblem ::= 4;
deliveryControlViolated ERROR PARAMETER NULL ::= 5;
deliveryControlViolated ERROR PARAMETER NULL ::= 5;
resourceError ERROR PARAMETER NULL ::= 6;
resourceError ERROR PARAMETER NULL ::= 6;
protocolViolation ERROR PARAMETER NULL ::= 7;
protocolViolation ERROR PARAMETER NULL ::= 7;
messageError ERROR PARAMETER NULL ::= 8;
messageError ERROR PARAMETER NULL ::= 8;
SecurityProblem ::= INTEGER (0..127);
SecurityProblem ::= INTEGER (0..127);
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.
提交控制违反错误报告MTS用户违反MTS通过提交控制服务对提交服务施加的控制。提交控件没有参数。
messageIdentifierInvalid
messageIdentifierInvalid
The Message Identifier Invalid error reports that the Message Identifier presented to the MTS is not considered valid.
消息标识符无效错误报告显示给MTS的消息标识符无效。
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.
安全错误报告MTS或MTS用户无法提供请求的操作，因为这将违反有效的安全策略。
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.
传递控制违反错误报告MTS违反MTS用户通过传递控制操作施加的传递操作控制。
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.
消息代理当前无法支持此操作。在分段和重新组装的情况下，resourceError由接收方用于请求发送方重新传输单个分段。
protocolViolation
协议违反
Indicates that one or more mandatory argument(s) were missing.
指示缺少一个或多个强制参数。
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.
为了确保在传递过程中不违反安全策略，将根据安全上下文检查消息安全标签。如果安全策略禁止交付，则根据安全策略，将为此生成报告指令。
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
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 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);
-- 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 EMSD-SA generating this id.
如果该消息源于RFC-822消息，则该EMSDMessageId应为该消息的“消息Id:”字段。如果该消息源于EMSD域，则该标识符对于生成该id的EMSD-SA而言应是唯一的。
EMSDMessageId ::= CHOICE
{
EMSDLocalMessageId [APPLICATION 4]
IMPLICIT EMSDLocalMessageId,
EMSDMessageId ::= CHOICE
{
EMSDLocalMessageId [APPLICATION 4]
IMPLICIT EMSDLocalMessageId,
rfc822MessageId [APPLICATION 5] IMPLICIT AsciiPrintableString
rfc822MessageId[应用程序5]隐式AsciiPrintableString
(SIZE (0..ub-message-id-length)) };
（大小（0..ub消息id长度））}；
EMSDLocalMessageId ::= SEQUENCE
{
submissionTime DateTime,
messageNumber INTEGER (0..ub-local-message-nu)
};
EMSDLocalMessageId ::= SEQUENCE
{
submissionTime DateTime,
messageNumber INTEGER (0..ub-local-message-nu)
};
EMSDORAddress ::= CHOICE
{
-- This is the local-format address
emsd-local-address-format EMSDAddress,
EMSDORAddress ::= CHOICE
{
-- This is the local-format address
emsd-local-address-format EMSDAddress,
-- This is a globally-unique RFC-822 Address rfc822DomainAddress AsciiPrintableString };
--这是一个全局唯一的RFC-822地址rfc822DomainAddress AsciiPrintableString}；
In the global sense Originators and Recipients are represented by EMSDORAddress. The rfc822Domain may be used to address any recipient.
在全球范围内，发起者和接收者由EMSDORAddress表示。RFC822域可用于向任何收件人发送地址。
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.
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 };
emsd名称[0]隐式八位字节字符串（大小（0..ub emsd名称长度））可选}；
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.
EMSD网络范围内的发起者和接收者通过基于数字的寻址方案进行识别。EMSDAddress只能在寻址范围明确限于EMSD网络的情况下使用。
DateTime ::= INTEGER;
DateTime ::= INTEGER;
DateTime is a Julian date, expressed as the number of seconds since 00:00:00 UTC, January 1, 1970.
DateTime是一个儒略日期，表示为自1970年1月1日UTC 00:00:00以来的秒数。
Iso8859String ::= GeneralString;
Iso8859String ::= GeneralString;
AsciiPrintableString ::= [APPLICATION 0]
IMPLICIT Iso8859String (FROM
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"|"{"|
"|"|"}"|"~"|"\"|""""));
(" "|"!"|"#"|"$"|"%"|"&"|"'"|"("|")"|"*"|"+"|","|"-"|"."|"/"|
"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,
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|
+------------------+-------+----+---------+----+---------+-----+-----+
+------------------+-------+----+---------+----+---------+-----+-----+
|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
表1:EMSD-P运营总结
version-minor [0] IMPLICIT INTEGER DEFAULT 0 }
次要版本[0]隐式整数默认值0}
Table 1 provides a comprehensive summary of EMSD-P operations, the SAP selectors used and the operation IDs used.
表1全面总结了EMSD-P操作、使用的SAP选择器和使用的操作ID。
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.
执行者通过使用SubmissionVerify操作实现非零而是一。当执行者收到FAILURE.indication时，其责任是通过使用SubmissionVerify解决问题，结果不是零而是一。
Submission procedure is as follows:
提交程序如下：
o Submit operation with 3-Way handshake and Duplicate Operation Detection Support Function is invoked.
o 使用三方握手提交操作，并调用重复操作检测支持功能。
o If performer at EMSD-SA receives FAILURE.indication, it invokes SubmissionVerify.
o 如果EMSD-SA的执行者收到FAILURE.indication，则调用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).
o 只有结果操作得到确认或操作得到验证（在故障指示的情况下），EMSD-SA才会发送消息。
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.
SubmissionVerify操作的语义至少为一次。这种类型的语义对应于调用程序不断尝试直到得到正确答复的情况。此操作可以执行多次而不会造成任何伤害。
Implications:
启示：
o MTS sends out the message if and only if it's sure that UA knows about it.
o MTS发送消息的前提是且仅当其确定UA知道该消息时。
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).
Deliver操作的语义正好是一次。精确一次意味着每个操作都只执行一次，不多也不少。此语义无法完全实现，如果在调用操作后，调用者有成功指示，执行者有失败指示，并且网络瘫痪，则操作的结果将为零（而不是一次）。
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.
执行者通过使用DeliveryVerify操作实现了非零而是一。当执行者收到FAILURE.indication时，它负责使用DeliveryVerify解决问题，结果不是零而是一。
Delivery procedure is as follows:
交付程序如下：
o Deliver operation with 3-Way handshake is invoked.
o 调用带有三向握手的传递操作。
o If performer at User Agent (device) receives FAILURE.indication, it invokes DeliveryVerify.
o 如果用户代理（设备）上的执行者接收到FAILURE.indication，它将调用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.
DeliveryVerify操作的语义至少为一次。这种类型的语义对应于调用程序不断尝试直到得到正确答复的情况。此操作可以执行多次而不会造成任何伤害。
Implications:
启示：
o A non-delivery report is sent by MTS only if the message is not delivered.
o 只有邮件未送达时，MTS才会发送未送达报告。
o The UA is responsible for notifying the MTS (through an explicit deliveryVerify) to make sure that a delivery report is sent out.
o UA负责通知MTS（通过明确的deliveryVerify）以确保发送交付报告。
4 DUPLICATE OPERATION DETECTION SUPPORT
4重复操作检测支持
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.
ESRO服务不会检测到重复的操作调用。因此，重复操作检测支持功能单元用于在多次调用同一操作实例时检测重复。调用程序为操作分配操作实例标识符，该操作实例标识符在对等执行者实体上用于检测相同操作的重复调用。
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.
通过调用程序向操作分配操作实例Id（参见第4.1.2节“操作实例标识符”），可以实现对重复检测的支持。使用重复检测支持调用操作时，执行者会记录操作实例标识符，并检查下一个操作是否存在重复。
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节“操作值”），操作实例Id由调用方分配，并作为操作参数的第一个字节发送。
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.
操作值分为两组。0到31之间的操作值不支持重复操作检测（0到31），32到63之间的操作值支持重复操作检测。
Duplicate Operation Detection Functional Unit checks for duplication only if Operation Value is in the range of 32 to 63.
重复操作检测功能单元仅在操作值在32到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).
当调用程序用户使用32到63范围内的操作值（这意味着支持重复检测的操作）时，用户应为操作指定操作实例ID（请参阅下一节）。
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 操作实例标识符为一个字节，可以有0到255的值。
o Operation Instance Identifier is sent as the first byte of the operations parameter (without encoding).
o 操作实例标识符作为操作参数的第一个字节发送（无编码）。
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 操作实例标识符的长度为8位，但根据执行者的能力，它可能保留0到127个操作实例标识符以进行重复检测。执行者配置文件定义了针对重复检查的未完成操作实例标识符的数量。当执行者配置文件指示支持0未完成的操作实例标识符时，表示它不支持重复操作检测。在这种情况下，任何时间点都应该只有一个未完成的操作。
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 实例ID检查本身不是ESRO的一部分。重复检测的使用由EMSD-P确定。操作32-63的操作实例ID是参数的第一个字节。重复检测SUUPPORT将该字节带出。
o The Instance ID is not subject to Basic Encoding Rules (BER).
o 实例ID不受基本编码规则（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 调用方用户在请求调用服务时为操作分配操作实例标识符。操作值应在支持重复检测的操作值范围内，即32到63。
o It's the responsibility of the user to choose Operation Instance Identifier in a way that uniqely and unambiguously identifies the operation.
o 用户有责任选择操作实例标识符，以唯一明确地标识操作。
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 从调用方的角度来看，假设具有相同操作实例标识符的两个操作完全相同，这意味着它们产生完全相同的结果。
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 操作实例标识符唯一地指定了一个非幂等操作，对这样一个操作的多次调用最终将导致相同的结果，因为重复实例被标识，并且操作不会执行多次。
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 从执行者的角度来看，假设具有相同操作实例标识符的两个操作应该执行一次，并且只能执行一次。
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 如果请求，执行方的重复操作检测支持功能单元检查的重复程度（即保留的未完成操作实例标识符的总数）可以与调用方通信，以同步调用。
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 重复操作检测支持的用户负责根据执行者配置文件及其在这方面的限制进行操作。此行为是基于要实现的操作的所需语义定义的。
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 在执行者侧，当接收到操作实例标识符时，与此最新操作实例标识符的距离大于或等于操作实例标识符编号的环绕范围的一半的先前操作实例标识符过期，即对于8位操作实例标识符，距离为128会导致旧操作实例标识符过期。
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.
o 调用方用户有责任使用连续的操作实例标识符编号，或者当调用方跳过一些操作实例标识符时，应该记住，如果执行方一侧有一个较小的操作实例标识符，且距离如上所述，则该标识符将过期。
5 EMSD PROCEDURE FOR OPERATIONS
5机电工程署运作程序
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.
以下各节显示了在实施EMSD消息传输服务器（MTS）和EMSD用户代理（UA）时使用的一般程序，在支持它们的操作中，可选择3路或2路握手。这些过程并不构成实现的完整行为规范。以下部分包含对实施者有用的信息。
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.
MTS和UA是事件驱动的。每个都等待任何可能的事件类型，并在接收到事件时对其进行处理。处理事件后，等待下一个事件。
The MTS is event-driven.
MTS是事件驱动的。
If it received an event from ESROS, then it could be any of the following types:
如果它从ESRO接收到事件，则可能是以下任何类型：
o Message submit indication;
o 消息提交指示；
o Message submit confirm and failure indication;
o 消息提交确认和故障指示；
o Result and Error indication for a deliver operation;
o 交付操作的结果和错误指示；
o DeliveryVerify indication;
o 发货确认指示；
o Result and Error indication for a submissionVerify operation;
o 提交验证操作的结果和错误指示；
o Result and Error indication for a submissionControl operation;
o 提交控制操作的结果和错误指示；
o DeliveryControl indication.
o 交付控制指示。
For an ESROS event responsibility is passed to the MTS performer (Section 5.1.1).
对于ESROS事件，将责任转交给MTS执行者（第5.1.1节）。
If the MTS received an event:
如果MTS收到事件：
o for message delivery, from the RFC-822 mailer;
o 对于消息传递，来自RFC-822邮递员；
o requesting submission controls upon the UA, or;
o 请求对UA进行提交控制，或；
o indicating an elapsed timer (meaning that it's time to re-attempt a message delivery)
o 指示已用计时器（意味着是时候重新尝试邮件传递了）
then responsibility is passed to the MTS invoker (Section 5.1.5).
然后将责任移交给MTS调用方（第5.1.5节）。
The MTS performer is responsible for processing the following operations, received from ESROS:
MTS执行者负责处理从ESRO收到的以下操作：
o Message-submission
o 邮件提交
o Delivery-control
o 交付控制
o Delivery-verify
o 交货检验
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.
MTS执行者应首先确保已收到INVOKE.indication。此时不应出现任何其他类型的基元，应忽略它。
If there's something wrong with the PDU or operation data, the MTS performer should send back an error to the proper invoker:
如果PDU或操作数据有问题，MTS执行者应向适当的调用程序发回错误：
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.
1. 发送ESROS错误请求，然后等待响应（确认或故障指示）。响应将在发生事件的同一SAP类型上发回。
2. Keep track of the type of request that was issued.
2. 跟踪发出的请求的类型。
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.
如果PDU或操作数据没有任何问题，则MTS执行者已从ESRO收到有效事件。这可以是任何定义的提交和交付协议操作。
1. The Message-submission operation first checks to see which SAP this Submit Request came in on.
1. 消息提交操作首先检查此提交请求来自哪个SAP。
2. The request could have arrived as 2-Way SAP (see #3) or a 3-Way SAP (see #7).
2. 请求可能以双向SAP（请参见#3）或三向SAP（请参见#7）的形式到达。
3. If the event arrived on the 2-Way SAP, consider this a protocol violation and ignore it.
3. 如果事件到达双向SAP，考虑这是违反协议并忽略它。
4. Wait for a response to the request. The response could be either an ERROR.confirm (see #5) or a FAILURE.indication (see #6).
4. 等待对请求的响应。响应可能是ERROR.confirm（请参见#5）或FAILURE.indication（请参见#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.
5. 错误。请求已被确认。UA知道提交的消息没有发送。因为有一个错误，没有更多的事情要做，所以返回。
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.
6. 如果ErrorRequest的结果是Failure.indication，则可以假设UA没有收到任何信息（ERROR.request PDU丢失），这意味着UA失败；或者3路确认丢失，这意味着UA实际上已收到ERROR.request PDU，并知道传递失败。无论哪种方式，都可以忽略该消息。没什么事可做了，所以回去吧。
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.
7. 如果事件是在三向SAP上收到的，则这是接收提交请求的正确SAP。发回结果请求并跟踪发出的原语。
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).
8. 现在等待对我们请求的响应。响应将是Result.confirm（参见#9）或Failure.indication（参见#13）。
9. The RESULT.request has been confirmed.
9. 请求的结果已被确认。
10. Submit the message to the RFC-822 mailer.
10. 将消息提交到RFC-822邮件发送程序。
11. Attempt, a number of times, to send the submitted message via the RFC-822 mailer. If the send was successful, then return.
11. 多次尝试通过RFC-822邮件发送提交的邮件。如果发送成功，则返回。
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.
12. 如果在重试次数最多后，无法发送该消息，则认为这是一个失败。由于UA假设提交成功，但现在尚未发送，因此必须生成一条全新的消息，即未送达消息，并将其发送给UA。完成后，返回。
13. A FAILURE.indication has occurred due to the previously issued RESULT.request.
13. 由于先前发出的RESULT.request，出现了FAILURE.indication。
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).
14. 向UA发出提交验证，以查看是否收到RESULT.request。将提交验证发送给UA有三种可能的结果：失败（请参见#15）、发送消息（请参见#16）或丢弃消息（请参见#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.
15. 失败——提交验证请求未到达UA，或者提交验证响应未返回。忽略消息并返回。
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.
16. 提交验证操作成功，这意味着UA收到了请求，并以一条消息响应，表示希望发送该消息。
17. Attempt, a number of times, to send the submitted message via the RFC-822 mailer.
17. 多次尝试通过RFC-822邮件发送提交的邮件。
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.
18. 如果消息已成功提交到RFC-822邮件程序，则返回。如果在重试次数最多后，消息无法发送消息，则认为这是一个失败。
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.
19. UA已经假定消息提交成功。现在，由于提交的消息尚未发送，因此必须生成一条全新的消息，即未送达消息，并将其发送给UA。完成后，返回。
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.
20. UA回复了一条消息，说明应该删除该消息。如果UA从未收到来自MTS的结果，这意味着它从未收到消息Id，因此必须通知用户消息无法提交，则可能发生这种情况。如果UA没有被验证消息的记录，也可能发生这种情况。这可能是因为消息记录已老化和过期，或者由于存储或内存限制，EMSD-UA无法保留所接收消息的记录。无事可做，所以请返回。
This operation can be processed immediately. After it is processed, the appropriate result is returned.
可以立即处理此操作。处理后，将返回相应的结果。
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.
当UA认为MTS没有收到来自先前发送的消息的结果指示时，就会发生此操作。UA希望确保MTS知道其已交付。MTS将确定它对指定消息的了解程度，并返回结果。这可以立即处理，因为它不需要处理重复检测。
The MTS invoker is responsible for processing the following operations, received from ESROS:
MTS调用方负责处理从ESRO收到的以下操作：
o Message-delivery
o 消息传递
o Submission-control
o 提交控制
o Submission-verify
o 提交验证
Submission-control
提交控制
Process the Submission Control request.
处理提交控制请求。
Message-delivery
消息传递
1. Check the User Agent's profile to determine the SAP.
1. 检查用户代理的配置文件以确定SAP。
2. Set the SAP to 3-Way.
2. 将SAP设置为3向。
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.
3. 在启用重复检测的情况下，在适当的SAP上发出INVOKE.request。由于发出INVOKE.request时可能出现本地错误，因此需要重试计数器。
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).
4. INVOKE.request的结果中可能有三个事件：ERROR.indication（请参见#5）、result.indication（请参见#9）或FAILURE.indication（请参见#10）。
5. An ERROR.indication was received, which means that the UA can't accept the message right now.
5. 收到错误指示，这意味着UA现在无法接受该消息。
6. If the reason was one of a transient nature, wait for a while and then send the Deliver Request again.
6. 如果原因是暂时性的，请等待一段时间，然后再次发送传递请求。
7. If the reason was one of a permanent nature, send back a non-delivery report to the originator.
7. 如果原因是永久性的，则向发起人发回未交付报告。
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.
8. 由于错误是永久性的，因此MTS必须发回一份未交付报告，然后记录不成功的交付以及UA的错误并返回。
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.
9. 结果。返回指示，这意味着交付成功。如果要求，向发起人发送交付报告，并记录成功交付和返回。
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.
如果UA配置文件指示要使用完整的模式，请跟踪此消息已成功传递的事实（就MTS而言），因此如果UA发送传递验证操作，我们知道我们认为要传递消息。
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.
10. 返回了FAILURE.indication，这意味着向UA获取交付请求或从UA获取响应时出现问题。在任何情况下，都没有收到响应，因此请求超时。等待一段时间，然后再次发送传递请求。
As long as a FAILURE.indication is returned and the number of retries has not been exceeded, keep trying to verify the delivery.
只要返回FAILURE.indication且未超过重试次数，请继续尝试验证传递。
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.
提交验证操作始终在双向SAP上发出。等待答复。如果没有响应，请求将排队并在稍后重试。
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.
1. 在禁用重复检测的情况下，在双向SAP上发出INVOKE.request。由于发出调用请求时可能出现本地错误，因此需要重试计数器。
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.
2. 已发出INVOKE.Request并收到响应。响应将是结果指示（见#3）或失败指示（见#4）。提交验证操作没有定义错误，因此此处不应出现错误指示。
3. A RESULT.indication was received. Either ResponseSendMessage or ResponseDropMessage, as specified in the PDU, will be returned.
3. 收到了结果。指示。将返回PDU中指定的ResponseSendMessage或ResponseDropMessage。
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.
4. 收到FAILURE.indication，这意味着向UA获取提交验证请求或从UA获取响应时出现问题。在任何情况下，都没有收到响应，因此请求超时。等待一段时间，然后需要再次尝试发送提交验证请求。
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.
向UA发出INVOKE.request，其中包含内容类型为未送达报告的提交操作。此操作始终在双向SAP上发布。等待答复。如果没有响应，请求将排队并在稍后重试。
1. Create a Submit operation.
1. 创建提交操作。
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.
2. 在启用重复检测的情况下，在双向SAP上发出INVOKE.request。由于发出调用请求时可能出现本地错误，因此需要的重试计数器。
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).
3. 已收到对INVOKE.Request的响应。响应将是结果指示（见#5）、错误指示（见#4）或故障指示（见#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.
4. 收到错误指示，这意味着UA不知道如何处理我们的未送达报告。这是UAs的问题，所以什么也不做，然后返回。
5. A RESULT.indication was received, which means we delivered a successful non-delivery report.
5. 收到RESULT.indication，这意味着我们成功提交了未交付报告。
6. The result is logged. Nothing more is needed, so return.
6. 结果被记录下来。不需要更多，所以返回。
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.
7. 收到FAILURE.indication，这意味着向UA获取提交请求或从UA获取响应时出现问题。在任何情况下，响应都不会发生，因此请求超时。等待一段时间，然后再次发送提交验证请求。
The User Agent is event-driven.
用户代理是事件驱动的。
If it received an event from ESROS, then it could be any of the following types:
如果它从ESRO接收到事件，则可能是以下任何类型：
o Message deliver indication;
o 信息传递指示；
o Message deliver confirm and failure indication;
o 消息传递确认和故障指示；
o Result and Error indication for a submit operation;
o 提交操作的结果和错误指示；
o Submission verify indication;
o 提交验证指示；
o Result and Error indication for a delivery verify operation;
o 交付验证操作的结果和错误指示；
o Result and Error indication for a delivery control operation;
o 交付控制操作的结果和错误指示；
o Submission control indication.
o 提交控制指示。
For an ESROS event responsibility is passed to the UA performer (Section 5.2.1).
对于ESROS事件，责任由UA执行者承担（第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).
如果UA收到一个事件，表明有来自用户的消息要提交，则责任将转移到UA调用方（第5.2.2节）。
The performer on the UA side is responsible for processing the following operations:
UA侧的执行者负责处理以下操作：
o Message Delivery
o 消息传递
o Submission Verification
o 提交验证
o Submission Control
o 提交控制
Message-delivery
消息传递
1. A Message-delivery request is received.
1. 收到消息传递请求。
2. Check for the correctness of the PDU. If the PDU is bad the see #3. If the PDU is good then see #8.
2. 检查PDU的正确性。如果PDU坏了，请参阅第3页。如果PDU良好，请参见第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.
3. 发送ESROS ERROR.request。如果请求通过3路SAP到达，则使用3路SAP获得结果。如果请求是通过双向SAP到达的，则使用双向SAP获得结果。跟踪发出的请求的类型。
4. Wait for the ESROS event. The result could be an ERROR.confirm (see #5) or a FAILURE.indication (see #7).
4. 等待ESROS事件。结果可能是错误.confirm（参见#5）或失败.indication（参见#7）。
5. The ESROS event was an ERROR.confirm
5. ESROS事件是一个错误。请确认
6. Log the message as the Non-Delivery was confirmed by the MTS and return.
6. 将邮件记录为MTS已确认未送达并返回。
7. If the ESROS event was a FAILURE.indication, that means one of two things has occurred:
7. 如果ESROS事件为FAILURE.indication，则表示发生了以下两种情况之一：
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.
A.MTS没有收到任何信息（ERROR.request PDU丢失），这意味着MTS不知道消息传递已被拒绝。在这种情况下，MTS最终将超时，并重新传输消息传递请求。
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.
B.三向确认丢失，这意味着MTS实际上已收到错误请求PDU，并知道传递失败。
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.
8. 发送ESROS RESULT.request。如果请求通过3路SAP到达，则使用3路SAP获得结果。如果请求是通过双向SAP到达的，则使用双向SAP获得结果。跟踪发出的请求的类型。
9. Wait for the ESROS event. The result could be an RESULT.confirm (see #10) or a FAILURE.indication (see #13).
9. 等待ESROS事件。结果可能是result.confirm（参见#10）或FAILURE.indication（参见#13）。
10. If the event is a RESULT.confirm, then the delivered message can now be given to the user.
10. 如果事件是RESULT.confirm，则现在可以将传递的消息提供给用户。
11. Deliver the message to the user.
11. 将消息传递给用户。
12. Log the message as Message Delivery Known to MTS.
12. 将消息记录为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.
13. 如果事件为FAILURE.indication，则如果交付是在3路SAP上进行的，则可以向MTS发出交付验证请求，以查看MTS是否实际获得了RSULT.request。如果传递是在双向SAP上进行的，则消息将传递给用户，如果MTS尚未收到RESULT.request，则稍后将重新传输该消息，并忽略重复的消息。
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.
14. 将消息传递给用户。由于收到FAILRUE.indication以响应RESULT.requst，这意味着MTS可能没有收到RESULT.request。MTS现在可以超时，并发送同一消息的另一份副本。保存消息以进行重复检测。
15. Log the fact that the message was delivered, but that the MTS might not be aware of it.
15. 记录消息已传递，但MTS可能不知道这一事实。
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.
16. 如果UA支持交付验证，并且交付请求是通过三向SAP发送的，请参见#17。如果这两个条件中有一个不正确，则返回。
17. Send a Delivery-verify request to see if the MTS got the RESULT.request.
17. 发送传递验证请求以查看MTS是否获得结果。请求。
There are three possible results from sending the delivery verification to the MTS: Fail (see #18), ResponseNonDelivery (see #20) or ResponseDelivery (see #23).
将交付验证发送到MTS有三种可能的结果：失败（见第18页）、响应未交付（见第20页）或响应交付（见第23页）。
18. Fail -- Delivery Verify request didn't reach the MTS, or the Delivery Verify response didn't get back to the UA.
18. 失败--传递验证请求未到达MTS，或者传递验证响应未返回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.
19. 将此记录为向用户发送消息，但MTS可能已向发起人发送未发送报告，即使UA确实向用户发送了消息。然后再回来。
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.
20. ResponseNonDelivery——Verify Response表示MTS现在知道（由于传递验证操作），消息已传递给用户，但未及时收到我们的结果。请求或传递验证操作，并且已向发起人发送未传递报告。
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
21. MTS没有及时从UA收到结果指示，表明消息已交付给用户。MTS已将未交付报告发送给
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.
发起者。UA必须让用户知道这一点。将邮件记录为已发送给用户，但未发送给发起人。
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.
22. 由于UA收到了对验证操作的响应，它知道MTS知道该消息传递，因此UA也知道它不会收到该消息的副本。UA现在可以从可能的重复项列表中删除此消息的消息Id。
23. ResponseDelivery -- Verify Response received from MTS.
23. ResponseDelivery——验证从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.
24. 这意味着MTS知道（因为MTS已收到UA发送的RESULT.request，或者因为MTS现在已收到UAs交付验证消息，通知UA已收到要交付给用户的消息。MTS是（或曾经是）如果要求，能够向发起人发送交付报告。将其记录为发送报告。
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.
25. 由于UA收到了对验证操作的响应，它知道MTS知道该消息传递，因此UA也知道它不会收到该消息的副本。UA现在可以从可能的重复项列表中删除此消息的消息Id并返回。
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.
可以立即处理此操作。处理后，将返回相应的结果。
The invoker on the UA side is responsible for processing the following operations:
UA端的调用方负责处理以下操作：
o Message-submission
o 邮件提交
o Delivery-control
o 交付控制
o Delivery-verify
o 交货检验
Message-submission
邮件提交
General procedures for UA's Message-submission mirror that of MTS's Message-delivery.
UA报文提交的一般程序与MTS报文提交的一般程序相同。
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.
1. 在启用重复检测的情况下，在3路SAP上发出INVOKE.request。由于UA可以在发出调用请求时获得本地错误，因此需要一个重试计数器。
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).
2. UA已发出INVOKE.Request。等待ESRO的响应。响应将是RESULT.indication（参见#5）、ERROR.indication（参见#3）或FAILURE.indication（参见#7）。
3. A ERROR.indicaiton was received, meaning that the MTS told says that it cannot accept the message.
3. 收到一个ERROR.indication，这意味着MTS表示无法接受该消息。
4. Log the MTS rejection and return
4. 记录MTS拒绝和返回
5. A RESULT.indication was received, which means that the Submission was successful.
5. 收到RESULT.indication，表示提交成功。
6. Log successful submission and return.
6. 记录成功的提交和返回。
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.
7. 收到FAILURE.indication，表示向MTS提交请求或从MTS返回响应时出现问题。在任何情况下，UA从未收到响应，因此请求超时。等待一段时间，然后再次发送提交请求。
8. The UA has exceeded the maximum number of retries. Let the user know, log the failure and return.
8. UA已超过最大重试次数。让用户知道，记录故障并返回。
Delivery-verify
交货检验
General procedures for UA's Delivery-verify mirror that of MTS's Submission-verify.
UA交付验证的一般程序与MTS提交验证的一般程序相同。
6 EMSD FORMAT STANDARDS
6机电工程署格式标准
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.
EMSD格式标准（EMSD-FS）是一种非文本形式的互联网邮件（RFC-822）信息压缩编码，有助于信息的高效传输。EMSD-FS与EMSD-P一起使用，但不是RFC-822的一般替代品。EMSD-FS定义了一种人际短消息的表示方法。它定义了“内容”编码（标题+正文）。虽然EMSD-FS包含端到端信息，但其范围仅限于点对点。
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.
EMSD格式标准的设计完全符合RFC-822[3]。在许多方面，EMSD-FS可以被认为是一种高效的编码器和解码器。通过使用EMSD-FS，RFC-822消息被转换为更紧凑的二进制编码。然后在EMSD-SA和EMSD-UA之间传输此更紧凑的消息。然后，可将压缩信息（以EMSD-FS表示）完整地转换回RFC-822。
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.
对于使用EMSD协议发起（提交）的消息，某些字段（例如，地址、消息id）可以具有特殊的形式，这些形式专门化并产生更紧凑的EMSD-FS编码。这些特殊形式是RFC-822消息的合法值。
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].
本规范使用ASN.1[X.208]表示信息对象。ASN.1的编码应基于基本编码规则（BER）[5]。本规范的未来版本将使用压缩编码规则（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.
本节使用了（O）“可选”、“默认”、“有条件”和（M）“强制性”的约定，这些约定明确了信息存在的要求。
An interpersonal message (IPM) consists of a heading and a body.
人际信息（IPM）由标题和正文组成。
IPM ::= SEQUENCE
IPM ::= SEQUENCE
{
{
heading Heading,
标题标题，
body Body OPTIONAL
车身可选
};
};
The fields that may appear in the Heading of an IPM are defined and described below.
IPM标题中可能出现的字段定义和描述如下。
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,
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,
-- 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,
--收件人和与每个收件人关联的标志的列表。PerRecipientFields的收件人数据序列大小（1..ub个收件人），
-- Flags applying to this entire message per-message-flags [1] IMPLICIT BIT STRING
--每个消息标志[1]隐式位字符串应用于整个消息的标志
{
-- 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),
{
-- 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),
-- 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,
--指示此消息是否已自动转发自动转发（4）}可选，
-- User-specified recipient who is to receive replies to this message. reply-to [2] IMPLICIT SEQUENCE SIZE (1..ub-reply-to) OF EMSDORAddress OPTIONAL,
--将接收对此邮件的答复的用户指定的收件人。回复[2]EMSDORAddress的隐式序列大小（1..ub reply to）可选，
-- Identifier of a previous message, for which this message
-- is a reply
replied-to-IPM EMSDMessageId 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,
--信息的主题。主题[3]隐式AscipPrintableString（大小（0..ub主题字段））可选，
-- 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,
-- 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,
--MIME版本（如果不是1.0）MIME版本[5]隐式AsciiPrintableString（大小（0..ub MIME版本长度））可选，
-- Top-level MIME Content Type mime-content-type [6] IMPLICIT AsciiPrintableString (SIZE (0.. ub-mime-content-type-length)) OPTIONAL,
--顶级MIME内容类型MIME内容类型[6]隐式AsciiPrintableString（大小（0..ub MIME内容类型长度））可选，
-- MIME Content Id mime-content-id [7] IMPLICIT AsciiPrintableString (SIZE (0.. ub-mime-content-id-length)) OPTIONAL,
--MIME内容Id MIME内容Id[7]隐式AsciiPrintableString（大小（0..ub MIME内容Id长度））可选，
-- 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
-- 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 };
[9] 隐式AsciiPrintableString（大小（0..ub mime内容传输编码））可选}；
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.
发起人标题字段（O）标识IPM的发起人。
Recipient-data
收件人数据
PerRecipientFields ::= SEQUENCE
{
recipient-address EMSDORAddress,
per-recipient-flags BIT STRING
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),
{
-- 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 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),
通知请求ipm返回（4），
-- Report Request Types
--报告请求类型
-- At most one of these should be set for a
-- particular recipient. "delivery" implies "non-delivery"
-- in addition.
report-request-non-delivery (5),
report-request-delivery (6),
-- 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 }
--发起者向接收者请求回复。请求回复（7）}默认{报告请求未送达}
};
};
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.
“主要收件人”标题字段标识作为IPM“主要收件人”的零个或多个用户。主要接受者可能是那些期望按照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.
Copy Recipients heading（复制收件人标题）字段标识作为IPM“复制收件人”的零个或多个用户。副本接收者可能是IPM传递给其以获取信息的那些用户。
recipient-type-copy
收件人类型副本
This field is set if the recipient is on the Carbon Copy (CC) list.
如果收件人在复印件（CC）列表中，则设置此字段。
recipient-type-blind-copy
收件人类型盲拷贝
This field is set if the recipient is on the Blind Carbon Copy (BCC) list.
如果收件人在密件抄送（BCC）列表中，则设置此字段。
The Blind Copy Recipients heading field (C) identifies zero or more users who are the intended blind copy recipients of the IPM.
盲拷贝收件人标题字段（C）标识了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.
上述短语“副本接收人”的含义与第6.2.1节中“副本接收人”的含义相同。盲拷贝收件人是指其角色既不向主收件人也不向副本收件人公开的收件人。
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.
在针对盲拷贝接收者的IPM实例中，该条件字段应存在并标识该用户。是否还应确定其他盲拷贝接收人是本地事务。如果IPM用于主要或副本接收人，则应不包含该字段。
notification-request-rn
通知请求
A receipt notification (rn) reports its originator's receipt, or his expected and arranged future receipt, of an IPM.
接收通知（rn）报告其发起人对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.
未接收通知（nrn）报告其发起人未能接收、接受或延迟接收IPM。
notification-request-ipm-return
通知请求ipm返回
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.
报告请求使MTS能够向MTS用户确认先前调用消息提交或探测提交抽象操作的一个或多个结果。
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.
对于邮件提交，report delivery表示已提交邮件是否已传递给一个或多个收件人。对于探测器提交，报告交付指示如果要提交消息，是否可以交付消息。
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.
当设置此字段时，表示发端人请求收件人发送一封邮件，以回复承载该请求的邮件。
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.
优先级字段（默认为正常）标识授权用户附加到IPM的优先级。它可以采用以下任一值：紧急、正常或非紧急。
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.
重要性标题字段（默认正常）标识授权用户对IPM的重视程度。它可以采用以下任一值：低、正常或高。
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.
自动转发标题字段（默认值为false）指示IPM是否是自动转发的结果。它是一个布尔值。
reply-to
答复
User-specified recipient or recipients who are to receive replies to this message.
用户指定的一个或多个收件人将接收对此邮件的答复。
replied-to IPM
回复IPM
The Replied-to IPM heading field (C) identifies the IPM to which the present IPM is a reply. It comprises an IPM identifier.
回复IPM标题字段（C）标识当前IPM作为回复的IPM。它包括一个IPM标识符。
This conditional field shall be present if, and only if, the IPM is a reply.
当且仅当IPM为回复时，此条件字段才应存在。
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.
注意-在转发上下文中，应注意区分转发IPM和转发IPM。此字段应标识应答响应的这两个IPM中的任何一个。
subject
主题
The Subject heading field (O) identifies the subject of the IPM. It corresponds to the "Subject:" field of RFC-822.
主题标题字段（O）标识IPM的主题。它对应于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.
扩展标题字段[D无扩展（即成员）]传递的信息不包含其他标题字段。它包括一组零个或多个IPMS扩展，每个扩展传递一个这样的信息项。
IPMSExtension ::= SEQUENCE
{
x-header-label AsciiPrintableString,
x-header-value AsciiPrintableString
};
IPMSExtension ::= SEQUENCE
{
x-header-label AsciiPrintableString,
x-header-value AsciiPrintableString
};
The types of body parts that may appear in the Body of an IPM are structured using the MIME specification.
IPM主体中可能出现的主体部分类型使用MIME规范进行结构化。
Body ::= SEQUENCE
{
compression-method [0] IMPLICIT CompressionMethod
OPTIONAL,
-- If compression method is not specified,
-- "no-compression" is implied.
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.
};
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.
CompressionMethod ::= INTEGER
{
-- Compression Methods numbered 0 to 63 are reserved for
-- assignment within this and associated specifications.
no-compression (0), lempel-ziv (1)
无压缩（0），lempel-ziv（1）
-- Compression Methods numbered between 64 and 127 may be
-- used on a bilaterally-agreed basis between peers.
} (0..127)
-- Compression Methods numbered between 64 and 127 may be
-- used on a bilaterally-agreed basis between peers.
} (0..127)
7 ACKNOWLEDGMENTS
7致谢
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.
在CDPD上的有限规模消息（LSM）和窄带PC上的pACT的背景下，AT&T无线服务（AWS）资助了与EMSD协议开发相关的工作。
8 SECURITY CONSIDERATIONS
8安全考虑
This protocol supports simple authentication of the originator's address by the EMSD-SA and simple authentication of EMSD-SA by EMSD-UA.
该协议支持EMSD-SA对发起者地址的简单身份验证和EMSD-UA对EMSD-SA的简单身份验证。
Mainstream Internet mail security mechanisms can be used in conjunction with the EMSD protocol.
主流互联网邮件安全机制可与EMSD协议结合使用。
9 AUTHOR'S ADDRESS
9作者地址
Mohsen Banan Neda Communications, Inc. 17005 SE 31st Place Bellevue, WA 98008
莫森·巴南·内达通讯有限公司，地址：华盛顿州贝尔维尤东南31号，邮编：98008
EMail: mohsen@neda.com
EMail: mohsen@neda.com
A EMSD-P ASN.1 MODULE
EMSD-P ASN.1模块
This section compiles in one place the complete ASN.1 Module for EM Submission and Delivery Protocol.
本节在一个地方汇编了完整的ASN.1 EM提交和交付协议模块。
EMSD-SubmissionAndDeliveryProtocol DEFINITIONS ::=
EMSD-SubmissionAndDeliveryProtocol DEFINITIONS ::=
BEGIN
开始
EXPORTS EMSDORAddress, AsciiPrintableString, ContentType, DateTime, EMSDMessageId, EMSDORAddress, ProtocolVersionNumber;
导出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;
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 Operation --
----------------------
submit ES-OPERATION
提交电子商务操作
ARGUMENT SubmitArgument
RESULT SubmitResult
ERRORS
{
submissionControlViolated,
securityError,
resourceError,
protocolViolation,
messageError
} ::= 33;
ARGUMENT SubmitArgument
RESULT SubmitResult
ERRORS
{
submissionControlViolated,
securityError,
resourceError,
protocolViolation,
messageError
} ::= 33;
SubmitArgument ::= SEQUENCE
{
-- Security features
security [0] IMPLICIT SecurityElement
OPTIONAL,
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,
--消息内容类型ContentType的内容类型，
-- -- THE CONTENT -- --
----内容----
-- The submission content content ANY DEFINED BY content-type
--提交内容由内容类型定义
};
};
SubmitResult ::= SEQUENCE
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
};
-- 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 --
--------------------------------
--------------------------------
-- Delivery Control Operation --
--------------------------------
deliveryControl ES-OPERATION
交付控制ES-OPERATION
ARGUMENT DeliveryControlArgument
RESULT DeliveryControlResult
ERRORS
{
securityError,
resourceError,
protocolViolation
} ::= 2;
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,
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,
--将哪些操作置于限制集中允许操作[1]隐式操作可选，
-- What maximum content length should be allowed permissible-max-content-length [2] IMPLICIT INTEGER (0..ub-content-length) OPTIONAL,
--应允许的最大内容长度允许的最大内容长度[2]隐式整数（0..ub content length）可选，
-- What is the lowest priority message which may be delivered permissible-lowest-priority [3] IMPLICIT ENUMERATED { non-urgent (0), normal (1), urgent (2) } OPTIONAL,
--可传递的最低优先级消息是什么允许的最低优先级[3]隐式枚举{非紧急（0）、正常（1）、紧急（2）}可选，
-- Security features security [4] IMPLICIT SecurityElement OPTIONAL,
--安全功能安全[4]隐式安全元素可选，
-- User Feature selection user-features [5] IMPLICIT OCTET STRING OPTIONAL };
--用户特征选择用户特征[5]隐式八位字节字符串可选}；
DeliveryControlResult ::= SEQUENCE
{
-- Operation types queued at the EMSD-SA due to existing
-- restrictions.
waiting-operations [0] IMPLICIT Operations DEFAULT { },
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
-- Types of messages queued at the EMSD-SA due to
-- existing restrictions
waiting-messages [1] IMPLICIT WaitingMessages DEFAULT { },
等待消息[1]隐式等待消息默认值{}，
-- Content Types of messages queued at the EMSD-SA
waiting-content-types SEQUENCE SIZE (0..ub-content-types) OF
ContentType 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)
};
Restrict ::= ENUMERATED
{
update (1),
remove (2)
};
Operations ::= BIT STRING
{
submission (0),
delivery (1)
};
Operations ::= BIT STRING
{
submission (0),
delivery (1)
};
WaitingMessages ::= BIT STRING
{
long-content (0),
low-priority (1)
};
WaitingMessages ::= BIT STRING
{
long-content (0),
low-priority (1)
};
-- Delivery Verify Operation
--交付验证操作
deliveryVerify ES-OPERATION
交付验证ES-OPERATION
ARGUMENT DeliveryVerifyArgument
RESULT DeliveryVerifyResult
ERRORS
{
verifyError,
resourceError,
protocolViolation
} ::= 5;
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
};
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
};
DeliveryVerifyResult ::= SEQUENCE
{
status DeliveryStatus
};
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)
};
DeliveryStatus ::= ENUMERATED
{
no-report-is-sent-out (1),
delivery-report-is-sent-out (2),
non-delivery-report-is-sent-out (3)
};
-----------------------
-- DELIVER Operation --
-----------------------
-----------------------
-- DELIVER Operation --
-----------------------
deliver ES-OPERATION
ARGUMENT DeliverArgument
RESULT NULL
ERRORS
{
deliveryControlViolated,
securityError,
resourceError,
protocolViolation,
messageError
} ::= 35;
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,
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,
--通过EMSD-SA消息传递时间日期时间将消息传递给收件人的时间，
-- 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,
-- 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,
--安全功能安全[1]隐式安全元素可选，
-- SegContentTypementation features for efficient transport segment-info SegmentInfo OPTIONAL,
--SegContentTypementation功能用于高效传输段信息SegmentInfo可选，
-- The type of the content content-type ContentType,
--内容类型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;
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,
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,
--将哪些操作置于限制集中允许操作[1]隐式操作可选，
-- What maximum content length should be allowed permissible-max-content-length [2] IMPLICIT INTEGER (0..ub-content-length) OPTIONAL,
--应允许的最大内容长度允许的最大内容长度[2]隐式整数（0..ub content length）可选，
-- Security features security [3] IMPLICIT SecurityElement OPTIONAL };
--安全特性安全[3]隐式安全元素可选}；
SubmissionControlResult ::= SEQUENCE
{
-- Operation types queued at the EMSD-SA due to existing
SubmissionControlResult ::= SEQUENCE
{
-- Operation types queued at the EMSD-SA due to existing
-- restrictions. waiting-operations [0] IMPLICIT Operations DEFAULT { }
--限制。等待操作[0]隐式操作默认值{}
};
};
----------------------------------
-- Submission Verify Operation --
----------------------------------
----------------------------------
-- Submission Verify Operation --
----------------------------------
submissionVerify ES-OPERATION
提交验证操作
ARGUMENT SubmissionVerifyArgument
RESULT SubmissionVerifyResult
ERRORS
{
submissionVerifyError,
resourceError,
protocolViolation
} ::= 6;
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
};
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
};
SubmissionVerifyResult ::= SEQUENCE
{
status SubmissionStatus
};
SubmissionStatus::= ENUMERATED
{
send-message (1),
drop-message (2)
};
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 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
getConfiguration电子操作
ARGUMENT NULL
RESULT NULL
ERRORS
{
resourceError,
protocolViolation
} ::= 7;
ARGUMENT NULL
RESULT NULL
ERRORS
{
resourceError,
protocolViolation
} ::= 7;
-- SetConfiguration Operation
-- To be fully defined later.
-- SetConfiguration Operation
-- To be fully defined later.
setConfiguration ES-OPERATION
SETES-OPERATION配置
ARGUMENT NULL
RESULT NULL
ERRORS
{
resourceError,
protocolViolation
} ::= 8;
ARGUMENT NULL
RESULT NULL
ERRORS
{
resourceError,
protocolViolation
} ::= 8;
-- Security --
--保安--
SecurityElement ::= SEQUENCE
SecurityElement ::= SEQUENCE
{
credentials Credentials,
contentIntegrityCheck ContentIntegrityCheck OPTIONAL
};
{
credentials Credentials,
contentIntegrityCheck ContentIntegrityCheck OPTIONAL
};
Credentials ::= CHOICE
{
simple [0] IMPLICIT SimpleCredentials
-- Strong Credentials are for future study
-- strong [1] IMPLICIT StrongCredentials
-- externalProcedure [2] EXTERNAL
};
Credentials ::= CHOICE
{
simple [0] IMPLICIT SimpleCredentials
-- Strong Credentials are for future study
-- strong [1] IMPLICIT StrongCredentials
-- externalProcedure [2] EXTERNAL
};
SimpleCredentials ::= SEQUENCE
SimpleCredentials ::= SEQUENCE
{
eMSDAddress EMSDAddress OPTIONAL,
password [0] IMPLICIT OCTET STRING
(SIZE (0..ub-password-length)) OPTIONAL
};
{
eMSDAddress EMSDAddress OPTIONAL,
password [0] IMPLICIT OCTET STRING
(SIZE (0..ub-password-length)) OPTIONAL
};
-- StrongCredentials ::= NULL
-- for now.
-- StrongCredentials ::= NULL
-- for now.
-- ContentIntegrityCheck is a 16-bit checksum of content
ContentIntegrityCheck ::= INTEGER (0..65535);
-- ContentIntegrityCheck is a 16-bit checksum of content
ContentIntegrityCheck ::= INTEGER (0..65535);
SegmentInfo ::= CHOICE
SegmentInfo ::= CHOICE
{
first [APPLICATION 2] IMPLICIT FirstSegment,
other [APPLICATION 3] IMPLICIT OtherSegment
};
{
first [APPLICATION 2] IMPLICIT FirstSegment,
other [APPLICATION 3] IMPLICIT OtherSegment
};
FirstSegment ::= SEQUENCE
FirstSegment ::= SEQUENCE
{ sequence-id INTEGER, number-of-segments INTEGER -- number-of-segments must not exceed ub-total-number-of-segments
{序列id整数，段数整数--段数不能超过段总数
};
};
OtherSegment ::= SEQUENCE
OtherSegment ::= SEQUENCE
{
sequence-id INTEGER,
segment-number INTEGER
};
{
sequence-id INTEGER,
segment-number INTEGER
};
-----------
-- Errors --
------------
-----------
-- Errors --
------------
protocolVersionNotRecognized ERROR PARAMETER NULL ::= 1;
protocolVersionNotRecognized ERROR PARAMETER NULL ::= 1;
submissionControlViolated ERROR PARAMETER NULL ::= 2;
submissionControlViolated ERROR PARAMETER NULL ::= 2;
messageIdentifierInvalid ERROR PARAMETER NULL ::= 3;
messageIdentifierInvalid ERROR PARAMETER NULL ::= 3;
securityError ERROR PARAMETER security-problem SecurityProblem ::= 4;
securityError ERROR PARAMETER security-problem SecurityProblem ::= 4;
deliveryControlViolated ERROR PARAMETER NULL ::= 5;
deliveryControlViolated ERROR PARAMETER NULL ::= 5;
resourceError ERROR PARAMETER NULL ::= 6;
resourceError ERROR PARAMETER NULL ::= 6;
protocolViolation ERROR PARAMETER NULL ::= 7;
protocolViolation ERROR PARAMETER NULL ::= 7;
messageError ERROR PARAMETER NULL ::= 8;
messageError ERROR PARAMETER NULL ::= 8;
SecurityProblem ::= INTEGER (0..127);
SecurityProblem ::= INTEGER (0..127);
-- -- 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
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 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);
-- 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.
-- 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))
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)
};
EMSDLocalMessageId ::= SEQUENCE
{
submissionTime DateTime,
messageNumber INTEGER (0..ub-local-message-nu)
};
-- An Originator/Recipient Address in EMSD Environment
--机电工程署环境中的发信人/收件人地址
EMSDORAddress ::= CHOICE
{
EMSDORAddress ::= CHOICE
{
-- This is the local-format address emsd-local-address-format EMSDAddress,
--这是本地格式地址emsd本地地址格式EMSDAddress，
-- This is a globally-unique RFC-822 Address rfc822DomainAddress AsciiPrintableString };
--这是一个全局唯一的RFC-822地址rfc822DomainAddress AsciiPrintableString}；
EMSDAddress ::= SEQUENCE
{
emsd-address OCTET STRING
(SIZE (1..ub-emsd-address-length)),
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-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 };
emsd名称[0]隐式八位字节字符串（大小（0..ub emsd名称长度））可选}；
DateTime ::= INTEGER;
DateTime ::= INTEGER;
Iso8859String ::= GeneralString;
Iso8859String ::= GeneralString;
AsciiPrintableString ::= [ APPLICATION 0 ]
IMPLICIT Iso8859String (FROM
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"|"{"|
"|"|"}"|"~"|"\"|""""));
(" "|"!"|"#"|"$"|"%"|"&"|"'"|"("|")"|"*"|"+"|","|"-"|"."|"/"|
"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
ProtocolVersionNumber ::= [APPLICATION 1] SEQUENCE
{
version-major INTEGER,
version-minor [0] IMPLICIT INTEGER DEFAULT 0
}
END -- end of EMSD-SubmissionAndDeliveryProtocol
B EMSD-IPM ASN.1 MODULE
B EMSD-IPM ASN.1模块
This section compiles in one place the complete ASN.1 Module for EMSD-IPM.
本节在一个地方编译了EMSD-IPM的完整ASN.1模块。
EMSD-InterpersonalMessaging1995 DEFINITIONS ::=
EMSD-InterpersonalMessaging1995 DEFINITIONS ::=
BEGIN
开始
IMPORTS EMSDORAddress, EMSDMessageId, AsciiPrintableString FROM EMSD-SubmissionAndDeliveryProtocol;
从EMSD SubmissionAndDeliveryProtocol导入EMSDORAddress、EMSDMessageId、AsciiPrintableString；
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;
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
IPM ::= SEQUENCE
{
heading Heading,
body Body OPTIONAL
};
{
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,
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,
-- 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,
--收件人和与每个收件人关联的标志的列表。PerRecipientFields的收件人数据序列大小（1..ub个收件人），
-- Flags applying to this entire message per-message-flags [1] IMPLICIT BIT STRING
--每个消息标志[1]隐式位字符串应用于整个消息的标志
{
-- 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),
{
-- 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),
-- 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,
-- 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,
-- 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,
-- 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,
--信息的主题。主题[3]隐式AscipPrintableString（大小（0..ub主题字段））可选，
-- 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,
-- 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))
--MIME版本（如果不是1.0）MIME版本[5]隐式AsciiPrintableString（大小（0..ub MIME版本长度））
OPTIONAL,
可选择的
-- Top-level MIME Content Type mime-content-type [6] IMPLICIT AsciiPrintableString (SIZE (0.. ub-mime-content-type-length)) OPTIONAL,
--顶级MIME内容类型MIME内容类型[6]隐式AsciiPrintableString（大小（0..ub MIME内容类型长度））可选，
-- MIME Content Id mime-content-id [7] IMPLICIT AsciiPrintableString (SIZE (0.. ub-mime-content-id-length)) OPTIONAL,
--MIME内容Id MIME内容Id[7]隐式AsciiPrintableString（大小（0..ub MIME内容Id长度））可选，
-- MIME Content Description mime-content-description [8] IMPLICIT AsciiPrintableString (SIZE (0.. ub-mime-content-description-length)) OPTIONAL,
--MIME内容描述MIME内容描述[8]隐式AsciiPrintableString（大小（0..ub MIME内容描述长度））可选，
-- Top-level MIME Content Type mime-content-transfer-encoding [9] IMPLICIT AsciiPrintableString (SIZE (0..ub-mime-content-transfer-encoding)) OPTIONAL };
--顶级MIME内容类型MIME内容传输编码[9]隐式AsciiPrintableString（大小（0..ub MIME内容传输编码））可选}；
PerRecipientFields ::= SEQUENCE
{
recipient-address EMSDORAddress,
per-recipient-flags BIT STRING
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),
{
-- 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),
-- Notification Request Types.
-- Only one of "rn" and "nrn" may be specified
-- concurrently, \x110011 for a single recipient.
-- "rn" implies "nrn" in addition.
notification-request-rn (2),
notification-request-nrn (3),
notification-request-ipm-return (4),
-- Report Request Types
-- At most one of these should be set for a
-- particular recipient. "delivery" implies "non-delivery"
-- in addition.
report-request-non-delivery (5),
report-request-delivery (6),
-- 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 }
--发起者向接收者请求回复。请求回复（7）}默认{报告请求未送达}
};
};
IPMSExtension ::= SEQUENCE
{
x-header-label AsciiPrintableString,
x-header-value AsciiPrintableString
};
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.
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.
};
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)
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)
-- Compression Methods numbered between 64 and 127 may be
-- used on a bilaterally-agreed basis between peers.
} (0..127)
END -- end of EMSD-InterpersonalMessaging1995
完—机电工程署-国际通讯1995年结束
C RATIONALE FOR KEY DESIGN DECISIONS
C关键设计决策的基本原理
This section summarizes the rationale behind key design decisions that were made while developing the EMSD Protocols.
本节总结了在制定EMSD协议时做出的关键设计决策背后的基本原理。
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.
SMTP是整个Internet上的主要邮件传输机制。SMTP被广泛部署，并为许多专门从事Internet电子邮件的工程师所理解。由于这些原因，基于SMTP或源于SMTP的作品更有可能在整个互联网上广泛部署。
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.
然而，SMTP对于短消息的传输效率非常低。SMTP的低效率既适用于传输的数量，也适用于传输的字节数。
Even when fully optimized with PIPELINING, SMTP is still quite inefficient.
即使使用管道进行了充分优化，SMTP仍然非常低效。
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).
使用SMTP提交短消息涉及15次传输。使用SMTP和管道传输提交短消息涉及9次传输。向EMSD（EMSD-P和ESRO）提交短消息涉及3次传输（在典型情况下）。
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.
推动机电工程署设计的关键要求是效率。据确定，效率至少提高了3倍，证明偏离SMTP模型是合理的。
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和管道、QMTP和EMSD传输短Internet电子邮件时交换的N-PDU数。用于识别PDU的名称是非正式名称。
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
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
client: message server: accept client: QUIT server: ok close client: close
客户端：消息服务器：接受客户端：退出服务器：确定关闭客户端：关闭
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.
为了提供与现有电子邮件协议为短消息提供的相同级别的可靠性，显然需要可靠的底层服务。UDP[6]本身显然是不够的。
Use of TCP however, involves three phases:
然而，TCP的使用涉及三个阶段：
1. Connection Establishment
1. 连接建立
2. Data Transfer
2. 数据传输
3. Disconnect
3. 断开
Reliable transfer of a short message using TCP at a minimum involves 5 transmissions as it is the case with QMTP.
与QMTP一样，使用TCP进行短消息的可靠传输至少需要5次传输。
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.
推动机电工程署设计的关键要求是效率。据确定，消除额外的2个传输（这是TCP的固有特性）可以证明偏离TCP是合理的。
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.
按照（RFC-2188[1]）中的规定，ESRO协议在UDP[6]之上以最小的开销提供可靠的无连接远程操作服务。ESRO协议支持分段和重组、连接和分离。
Reliable transfer of a short message using ESRO involves 3 transmissions as it is the case with EMSD-P.
与EMSD-P一样，使用ESRO可靠传输短消息需要3次传输。
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.
许多互联网协议是“基于文本的”。很少有互联网协议是基于RPC的。围绕“基于文本”的方法设计的协议在整个互联网上有更好的接受记录。
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.
考虑到在机电工程署中，信息提交和传递只涉及两次数据交换，基于文本的模型与操作相同。此外，RPC模型是使用ESRO的自然方式。
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.
在当今的编码机制中，ASN.1具有将抽象语法与编码规则分离的独特特性。通过选择ASN.1作为表示机电工程署信息对象的符号，机电工程署可以灵活地使用最有效的编码规则，如压缩编码规则（PER）。
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.
当信息的语法已知时，总是可以更好地执行高效编码。一般来说，使用信息语法知识的编码和压缩技术比处理任意文本的压缩技术产生更好的结果。
D FURTHER DEVELOPMENT
D进一步发展
Beyond this documentation of existing implementations, further development of EMSD protocol is anticipated.
除了现有实现的文档之外，预计还会进一步开发EMSD协议。
The following deficiencies and areas of improvement are identified.
确定了以下缺陷和改进领域。
o Mapping of RFC-822 to EMSD-FS needs to be more explicit.
o RFC-822到EMSD-FS的映射需要更加明确。
o Mapping of EMSD-FS to RFC-822 needs to be more explicit.
o EMSD-FS到RFC-822的映射需要更加明确。
o Text of duplicate detection section needs more structure.
o 重复检测部分的文本需要更多的结构。
o SubmissionControl operation needs more informative description.
o SubmissionControl操作需要更详细的说明。
o Based on implementor's feedback the "EMSD PROCEDURE FOR OPERATIONS" section needs to be adjusted or re-done.
o 根据实施者的反馈，“EMSD操作程序”部分需要调整或重新完成。
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 除了EMSD-FS之外，EMSD协议还可以扩展，以支持原始RFC-822文本消息的传输。这将是“易于实现”与“传输字节的效率”之间的权衡。
o Provide mechanisms to support fully automated initial provisioning of mail-boxes.
o 提供支持邮箱完全自动化初始资源调配的机制。
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/.
预计机电工程署的未来发展将在http://www.emsd.org/. 有意进一步开发和维护本协议的人士，请加入托管在http://www.emsd.org/.
E. References
E.参考资料
[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.
[1] Banan，M.，Cheng，J.和M.Taylor，“At&t/neda的高效短距离远程操作（ESRO）协议规范1.2版”，RFC 2188，1997年9月。
[2] Bradner, S., "Key words for use in RFCs to indicate requirement levels", BCP 14, RFC 2119, March 1997.
[2] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[3] Crocker, D., "Standard for the format of ARPA internet text messages", STD 11, RFC 822, August 1982.
[3] Crocker，D.，“ARPA互联网文本信息格式标准”，STD 11，RFC 822，1982年8月。
[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.
[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.
[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.
[6] Postel，J.，“用户数据报协议”，STD 6，RFC 768，1980年8月。
F. Full Copyright Statement
F.完整的版权声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。