Network Working Group M. Banan
Request for Comments: 2524 Neda Communications, Inc.
Category: Informational February 1999
Neda's
Efficient Mail Submission and Delivery (EMSD)
Protocol Specification Version 1.3
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（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 [RFC 2188]、上に積層されています。これは、公共のインターネットを介したエンドツーエンドの使用のためEMSDが完全に適しません。 < - >二つの領域間のSMTPゲートウェイEMSDは、すべてのEMSDメールがワイヤレスネットワークと公衆インターネット意志トランジットの間でEMSDを交換した場合にのみ、ワイヤレスネットワークでの使用を考慮すべきです。
- 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.
EMSDはASCIIレパートリーの外や言語タグの文字の表現するための規定を持っていません。
- Poorly defined gatewaying to and from Internet Mail
- へとインターネットメールの定義が不十分ゲートウェイ
Because Internet Mail and EMSD have somewhat different and conflicting service models and different data models, mapping between them may provide good service only in limited cases, and this may cause operational problems.
インターネットメールとEMSDは多少異なると矛盾するサービスモデルと異なるデータモデルを持っているので、それらの間のマッピングは、限られたケースでは良いサービスを提供することができ、これは操作上の問題を引き起こす可能性があります。
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は、したがって、どちらかのみ使用し、メッセージ（ASCIIテキストの数百バイトを超えない）の長さおよびフォーマットに固有の制限を持つデバイスと通信するために、即ち、EMSD展開が状況を狭くするために限定されることをお勧めします。
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は非常に提出し、短いインターネットメールメッセージの配信用に最適化されたメッセージングプロトコルです。 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.
この仕様は狭く効率に明確な重点を置いて提出し、ショートメールメッセージの配信に焦点を当てています。 EMSDを念頭に置いて、無線ネットワーク（例えば、CDPD、ワイヤレスIP、モバイルIP）使用に特別に設計されています。 EMSDは、メール送信やメール配信の効率化が重要な場合、インターネットメールプロトコルの主流に自然な拡張できるように設計されています。そのため、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]で指定されたEMSDプロトコルは、効率的なショートリモート操作（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.
ほとんどの既存のインターネットメールプロトコルは効率的ではありません。ほとんどの既存のインターネットメールプロトコルは、二つの主要な要件として、SMTPの伝統を持つシンプルさと継続して設計されています。 EMSDは主要な要件として効率的に設計されています。
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インターネットメール発信と配信。 。 。 。他のメールプロトコルにEMSDのうち4 1.2の関係。 。 。 5つの1.3 EMSDの要件と目標。 。 。 。 。 。 。 EMSD 7つの1.4期待される使用法。 。 。 。 。 。 。 。本明細書において使用される用語の8つの1.5定義。 。本明細書中で使用される9つの1.6表記。 。 。 。この仕様について9 1.7。 。 。 。 。 。 。 。下層10 2効率的なメール送信および配信の概要10 3効率的なメール送信と配信PROTOCOL 11 3.1使用。 。 。 。 。 。 。 。 。 ESROSの13 3.1.1使用。 。 。 。 。 。 。 。 。 UDPの13 3.1.2使用。 。 。 。 。 。 。 。 。 。 13の3.1.3符号化規則。 。 。 。 。 。 。 。 。 13 3.1.4プレゼンテーションコンテキスト。 。 。 。 。 。 。 14 3.2 EMSD-UA呼び出されます操作。 。 。 。 。 。 。 14 3.2.1提出します。 。 。 。 。 。 。 。 。 。 。 14 3.2.2 deliveryControl。 。 。 。 。 。 。 。 17 3.2.3 deliveryVerify。 。 。 。 。 。 。 。 。 21 3.3 EMSD-SA呼び出さ操作。 。 。 。 。 。 。 23 3.3.1届けします。 。 。 。 。 。 。 。 。 。 23 3.3.2 submissionControl。 。 。 。 。 。 。 。 25 3.3.3 submissionVerify。 。 。 。 。 。 。 。 28個の3.4 EMSD共通情報オブジェクト。 。 。 。 。 。 30 3.4.1 SecurityElements。 。 。 。 。 。 。 。 30 3.4.2メッセージのセグメンテーションとリアセンブリ。 。 。 30の3.4.3一般的なエラー。 。 。 。 。 。 。 。 。 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提出し、配達手続き。 。 。 。 。 38 4 DUPLICATE操作検出SUPPORT 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 OPERATIONS 42 5.1 MTSの行動の5 EMSDの手順。 。 。 。 。 。 。 。 。 。 。 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 EMSDフォーマット規格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モジュールSMTPモデルから重要な設計決定78 C.1偏差を63 B EMSD-IPM ASN.1モジュール74 C根拠。 。 。 。 。 。 78 SMTP及びEMSD効率のC.1.1比較。 。 。代わりに、TCPのESROの78 C.2使用。 。 。 。 。 。 。リモートプロシージャコール（RPC）、モデルの79 C.3使用。 。 。 。 ASN.1 79 C.4使用。 。 。 。 。 。 。 。 。 。 。 80 D更なるDEVELOPMENT 81 E 82 F FULL著作権表示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.
スプリット-MUAモデルでは、ユーザーにメッセージを取得には、POPやIMAPなどのプロトコルを介してサーバー上のメールボックスへのアクセスを介して行われます。スプリット-MUAモデルでは、そのメッセージへのユーザのアクセスは、ユーザーが自分のメールボックスをポーリングするために必要とされる「メッセージプル」パラダイムです。 「メッセージのプッシュ」パラダイムに基づいて適切なメッセージ配信は、現在サポートされていません。 EMSDプロトコルは、効率性に重点を置いたこの欠点に対処しています。
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.
さまざまなインターネットメールプロトコルは、メール処理に様々な機能の達成を促進します。
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 | | |
+------------------+------+-------+-----+------+
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」ESの数は、特定の機能が特定のプロトコルでサポートされている程度を表します。
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
メール送信やショートメッセージの送達のためEMSDは、送信されたパケットの数に関して及び送信されたバイト数の点で両方の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でEMSDを比較し、さまざまな効率の研究が可能です。 SMTPとEMSDの効率性の比較についての詳細は、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.既存のインターネットメールプロトコルが提供する機能（またはそれ以上）の同じレベルを持つショートメールメッセージの提出を提供します。
2. Provide for delivery of short mail messages with the same level of functionality (or higher) that the existing Internet mail protocols provide.
2.既存のインターネットメールプロトコルが提供する機能（またはそれ以上）の同じレベルを持つショートメールメッセージの送達を提供します。
3. Function as an extension of the existing mainstream Internet mail.
既存の主流のインターネットメールの拡張として3機能。
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).
メモリおよびCPUレベルを含む、ならびにバッテリ電源の寿命（即ち、クライアント光とサーバ重い）：9.効率的な電力とに対するモバイルプラットフォームリソースう。
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.
かなりの帯域幅と容量制限があり、任意のネットワークおよびネットワークオペレータは、EMSDの使用の恩恵を受けることができます。測定されたネットワークを使用するため、高い費用を負担しなければならない任意のネットワークユーザーは、EMSDの使用の恩恵を受けることができます。
Initial uses of EMSD is anticipated to be primarily over IP-based wireless networks to provide two-way paging services.
EMSDの初期の用途は主に、双方向ページングサービスを提供するために、IPベースの無線ネットワーク上であることが予想されます。
EMSD can also function as an adjunct to Mail Access Protocols for "Mail Notification Services".
EMSDまた、「メール通知サービス」のためのメールアクセスプロトコルの補助として機能させることができます。
Considering:
考えます：
o that most wireless networks shall converge toward being IP-based;
ほとんどのワイヤレスネットワークは、IPベースのものに向かって収束するものとO;
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ベースの双方向ページングおよびインターネット電子メールの収束を容易にするために設計されています。
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からのメールの配信を受け付けるアプリケーションプロセス。効率的なメール発信や配信ユーザーエージェント（UA-EMSD）：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].
で定義されているキーワード "MUST" は、 "MUST NOT"、 "SHOULD NOT"、および本明細書中で解釈されるべきである、 "MAY"、 "SHOULD" [2]。
This specification uses the ES-OPERATION notation defined in Efficient Short Remote Operations (ESRO) protocols as specified in RFC-2188 [1].
この仕様は、RFC-2188で指定されるように効率的なショートリモート操作（ESRO）プロトコルで定義されたES-OPERATION表記を使用した[1]。
Operations and information objects are typically described using the ES-OPERATION and ASN.1 notations in the relevant sections of the specification.
操作情報オブジェクトは、典型的には、本明細書の関連セクションにES-動作及び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.
このプロトコル仕様は情報RFCとしてタイムリーに公表するために1998年10月23日に提出されています。
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間でメッセージを転送するために使用されている - Serverエージェントが（例えば、メッセージセンター）と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:
ユーザーエージェント（UA-EMSD）とEMSD - - サーバエージェント（EMSD-SA）この仕様は、EMSD間のプロトコルを定義します。 EMSD - P＆FSは、2つの独立したコンポーネントで構成されています
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 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.
EMSD-FSメッセージの効率的な転送を容易にするインターネットメールのコンパクトな符号化の非テキスト形式（RFC-822）メッセージです。 EMSD-FSは、EMSD-Pと一緒に使用されるが、RFC-822のための一般的な置換ではありません。 EMSD-FSは、短い対人メッセージの表現方法を定義します。これは、「コンテンツ」のエンコーディング（ヘッダ+ボディ）を定義します。 EMSD-FSは、エンドツーエンドの情報が含まれていますが、その範囲は、純粋にポイントツーポイントです。 EMSD-FSは、その受信者へのコンテンツの転送のために（2下記参照）EMSD-Pに依存しています。
This is described in the section entitled EMSD Format Standards.
これは、セクションと題したEMSDフォーマット規格に記述されています。
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は、ポイントツーポイントエンベロープに（上記1参照）EMSD-FSのメッセージをラップする責任があり、それを提出又は送達します。 RFC-2188に指定されているEMSD-Pは、ポイント・ツー・ポイントの封筒を輸送するための[1]効率的なショートリモート操作サービス（ESROS）のサービスに依存しています。 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されている2つの点。サービスのエンドツーエンド（他のメッセージング発信や受信者へのEMSD-User）を提供し、インターネットメール環境の要素として、EMSD-P機能。
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.
効率的なメール発信やデリバリーサービスは、効率的なショートリモート操作サービス（ESROS）を使用します。重複操作検出サポート機能と題されたセクションで説明したように彼らはまた、複製操作検出サポート機能を使用しています。これらの機能は、操作が一回以下で実行されないことを保証します。
3 EFFICIENT MAIL SUBMISSION AND DELIVERY PROTOCOL
3効率的なMAILの提出と配信プロトコル
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-SAへEMSD-UAからメッセージを転送する処理です。 EM DeliveryはEMSD-UAにEMSD-SAからのメッセージを転送する処理です。
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.
メッセージ投稿サービスは、1つのまたは複数の受信者への転送と配信のためのEMSD-SAにメッセージを提出するEMSD-UAを可能にします。 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-UAにメッセージを配信するEMSD-SAを可能にします。 EMSD-SAによって呼び出さ - - 送達操作のメッセージ配信サービス含む、おそらくdeliverVerify動作 - EMSD-UAによって呼び出されます。
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 | | | | |
| | +---+ +---+ | +---+ |
| | | |
| +-------------------------+ |
| |
| |
+---------------------------------------------+
Figure 2: Efficient Mail Submission and Delivery Protocol
図2：効率的なメール発信や配信プロトコル
o Delivery-control (the deliveryControl operation).
O送達制御（deliveryControl動作）。
EMSD-SA uses the following services:
EMSD-SAは、以下のサービスを使用しています：
o Message-delivery o Submission-control (the submissionControl operation).
Oメッセージ配信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）で指定されESROSのモデルに基づいて、リモート操作を発現する[1]。 （RFC-2188）のES-OPERATION表記は、特定の操作を定義するために本明細書を通して使用されます。
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.
で指定されESROプロトコル（RFC-2188 [1]）は、最小限のオーバーヘッドで[6] UDPの上に信頼性の高いコネクションレス遠隔操作サービスを提供します。 ESROプロトコルは、セグメント化および再組み立て、連結と分離をサポートしています。
ESRO Services (2-Way and 3-Way handshake) shall be used by the EMSD-P.
ESROサービス（2ウェイおよび3ウェイハンドシェイク）がEMSD-Pによって使用されなければなりません。
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ポート番号の指定が含まれます。換言すれば、ESROのSAPのEMSD-Pの使用はESROの642このような使用は、帯域幅効率にもたらすESROの設計上の特徴であるとされたポート以外のUDPポートを使用する他のプロトコルによって同じSAPセレクタの使用を排除するものではありませんないスケーラビリティの制限。
Use of Basic Encoding Rules (BER) [5] is mandatory for both EMSD Format Standards and EMSD Protocol.
基本符号化規則（BER）を使用すると、[5] EMSDフォーマットの標準とEMSDプロトコルの両方のために必須です。
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. OCTET STRINGとビット列の値、および「プリミティブ」または「構築」のいずれかとして符号化することができる任意の他の天然のASN.1タイプは、常に「プリミティブ」として符号化されなければならないと「構築ない」ことがないしなければなりません。
Parameter Encoding Type of "0" MUST be used in ESRO Protocol to identify Basic Encoding Rules for operation arguments.
「0」のパラメータのエンコーディングタイプは、操作の引数のための基本的な符号化規則を識別するためにESROプロトコルで使用されなければなりません。
The following operations are invoked by EMSD-UA:
以下の操作は、EMSD-UAによって呼び出されます。
a. submit
A。提出する
b. deliveryControl
B。 deliveryControl
c. deliveryVerify
C。 deliveryVerify
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.
提出ES-OPERATIONは、1人以上の受信者へ転送および配信のためEMSD-SAにメッセージを送信するEMSD-UAを可能にします。
submit ES-OPERATION
ES-OPERATIONを提出
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-操作が正常に完了は、EMSD-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,
-- Segmentation features for efficient transport segment-info SegmentInfo OPTIONAL,
- 効率的な輸送セグメント情報SegmentInfoオプションのためのセグメンテーション機能、
-- 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、 "SecurityElements" を参照してください。
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
{
-- 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-動作が一時EMSD-SAが呼び出すことができることを操作し、EMSD-SAメッセージ配信ES-操作によってEMSD-UAに配信できるメッセージを限定することをEMSD-UAを可能にします。
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-動作がEMSD-SAが起動、またはEMSD-SAが提供するであろう任意のメッセージタイプであろうと、任意のES-操作の指示を返し、それが優勢なコントロールのためではなかったです。
Arguments
引数
This operation's arguments are:
この操作の引数は次のとおりです。
DeliveryControlArgument ::= SEQUENCE
{
-- Request an addition of or removal of a set of restrictions
restrict [0] IMPLICIT Restrict DEFAULT update,
、[0] IMPLICITデフォルトの更新を制限する制限
-- Which operations are to be placed in the restriction set permissible-operations [1] IMPLICIT Operations OPTIONAL,
- どの操作は、[1] IMPLICIT操作OPTIONAL許容オペレーションを設定する制限内に配置されます
-- What maximum content length should be allowed permissible-max-content-length
- どのような最大のコンテンツ長は許容-MAX-コンテンツ長を許可する必要があります
[2] IMPLICIT INTEGER
(0..ub-content-length) OPTIONAL,
-- What is the lowest priority message which may be delivered permissible-lowest-priority
- 許容-最低の優先度を送達することができる最低の優先度のメッセージを何ですか
[3] IMPLICIT ENUMERATED
{
non-urgent (0),
normal (1),
urgent (2)
} OPTIONAL,
-- Security features security [4] IMPLICIT SecurityElement OPTIONAL,
- セキュリティは、[4] IMPLICIT SecurityElementオプションのセキュリティを備え
-- User Feature selection user-features [5] IMPLICIT OCTET STRING OPTIONAL };
- ユーザ特徴選択ユーザー機能[5] IMPLICIT OCTET STRINGをOPTIONAL}。
Restrict
制限します
This argument indicates whether the controls on ES-OPERATIONS are to be updated or removed. It may be generated by the EMSD-UA.
この引数は、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-操作を示します。これは、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-操作を起動してもしなくてもよいです。そして
o Other ES-OPERATIONS are not subject to controls, and may be invoked at any time.
他ESオペレーション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-操作は変更されません。
Permissible-max-content-length
許容-MAX-コンテンツ長
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が提供するES-操作によって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が提供するES-操作によって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.
非緊急または緊急、通常：この引数は提出ES-業務の優先順位引数の次のいずれかの値を有することができます。
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、 "SecurityElements" を参照してください。
User-features
ユーザーの特徴
This argument contains information that allows the EMSD-UA to convey to MTS the feature set that the user is capable of supporting. This argument will be defined when the setConfiguration and getConfiguration operations are defined.
この引数は、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 { },
-- Types of messages queued at the EMSD-SA due to -- existing restrictions waiting-messages [1] IMPLICIT WaitingMessages DEFAULT { },
- メッセージの種類に起因しEMSD-SAでキューに入れ - - メッセージ待機既存の制限[1] IMPLICIT WaitingMessagesデフォルト{}、
-- Content Types of messages queued at the EMSD-SA waiting-content-types SEQUENCE SIZE (0..ub-content-types) OF ContentType DEFAULT { }
- メッセージのコンテンツタイプは} {EMSD-SA待ちコンテンツタイプの配列サイズで（0..ubコンテンツ・タイプ）のContentTypeデフォルトのキューイング
};
｝；
Restrict ::= ENUMERATED
{
update (1),
remove (2)
};
Operations ::= BIT STRING
{
submission (0),
delivery (1)
};
WaitingMessages ::= BIT STRING
{
long-content (0),
low-priority (1)
};
｝；
Waiting-operations
待って、操作
This result indicates the ES-OPERATIONS being held by the EMSD-SA, and that the EMSD-SA would invoke on the EMSD-UA if it were not for the prevailing controls. It may be generated by the EMSD-SA.
この結果は、EMSD-SAによって保持されているES-動作を示し、それは支配的なコントロールがなかった場合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-操作を配信起動あろう。
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-操作によって送達します。これは、EMSD-SAによって生成することができます。
This result may have one or more of the following values:
この結果は、以下の値の1つ以上を有することができます。
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-操作は、それがESオペレーションを実現するためのFAILURE.indicationを受信したときにメッセージの配信を確認するEMSD-UAを可能にします。
deliveryVerify ES-OPERATION
deliveryVerify ES-OPERATION
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
{ -- 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 };
{ - このメッセージの識別子。提出結果に元に提供された - これは、同じ識別子です。 - 、メッセージ識別子の割り当てに関するコメントを参照してください - EMSDMessageIdの定義で。メッセージ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
};
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
配達-レポート-IS-送らアウト
This result indicates that EMSD-SA has received the delivery verify and has sent the delivery report out.
この結果は、EMSD-SAは、検証の配信を受けており、配信レポートを送信したことを示しています。
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。 submissionControl;
c. submissionVerify.
C。 submissionVerify。
The deliver operation uses 3-Way handshake service of ESROS. This operation always uses the duplication detection functional unit.
お届け操作はESROSの3ウェイハンドシェイクサービスを使用しています。この操作は、常に重複検出機能ユニットを使用しています。
The submissionControl and submissionVerify operations use 2-Way handshake service of ESROS without duplication detection.
submissionControlとsubmissionVerify操作は、重複検出なしESROSの2ウェイハンドシェイクサービスを使用します。
The deliver ES-OPERATIONS enables the EMSD-SA to deliver a message to an EMSD-UA.
送達ES-操作がEMSD-UAにメッセージを配信するEMSD-SAを可能にします。
deliver ES-OPERATION
ES-OPERATIONをお届け
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.
配信が力に、その後deliveryControl制限に違反しないかぎり、EMSD-UAは、ES-OPERATIONをお届け実行を拒否してはいけません。
Arguments
引数
This operation's arguments are:
この操作の引数は次のとおりです。
DeliverArgument ::= SEQUENCE
{
-- Identifier of this message. This is the same identifier that
-- was provided to the originator in the Submission Result.
-- See comment regarding assignment of message identifiers,
-- at the definition of EMSDMessageId.
message-id EMSDMessageId,
-- Time the message was delivered to the recipient by EMSD-SA message-delivery-time DateTime,
- メッセージがEMSD-SAメッセージ配信時間のDateTimeによって受信者に配信された時刻、
-- Time EMSD-SA originally took responsibility for processing -- of this message. This field shall be omitted if the message-id -- contains an EMSDLocalMessageId, because that field contains -- the submission time within it. message-submission-time [0] IMPLICIT DateTime OPTIONAL,
- このメッセージの - 時間EMSD-SAは、元々の処理のための責任を取りました。提出時間をその中に - そのフィールドが含まれているため、EMSDLocalMessageIdが含まれています - メッセージIDがあれば、このフィールドは省略されなければなりません。メッセージ提出時間[0] IMPLICIT日時OPTIONAL、
-- Security features security [1] IMPLICIT SecurityElement OPTIONAL,
- セキュリティは、[1] IMPLICIT SecurityElementオプションのセキュリティを備え
-- SegContentTypementation features for efficient transport segment-info SegmentInfo OPTIONAL,
- 効率的な輸送セグメント情報SegmentInfoオプションについてSegContentTypementation機能、
-- 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;
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-操作が一時EMSD-UAを呼び出すことができることを操作し、EMSD-UAが送信ES-操作によってEMSD-SAに提出することができるメッセージを限定することを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-操作とメッセージを後でまで保持するのではなく、放棄する必要があります。
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のsubmissionControl ES-操作を再呼び出しされるまで有効のままです。
The ES-OPERATIONS returns an indication of any ES-OPERATIONS that the EMSD-UA would invoke were it not for the prevailing controls.
ES-操作は、それが優勢なコントロールのためではなかったEMSD-UAを呼び出すであろう任意のES-操作の指示を返します。
Arguments
引数
This operation's arguments are:
この操作の引数は次のとおりです。
SubmissionControlArgument ::= SEQUENCE
{
-- Request an addition of or removal of a set of restrictions
restrict [0] IMPLICIT Restrict DEFAULT update,
-- Which operations are to be placed in the restriction set permissible-operations [1] IMPLICIT Operations OPTIONAL,
- どの操作は、[1] IMPLICIT操作OPTIONAL許容オペレーションを設定する制限内に配置されます
-- What maximum content length should be allowed permissible-max-content-length [2] IMPLICIT INTEGER (0..ub-content-length) OPTIONAL,
- 最大どのようなコンテンツの長さが許容-MAX-コンテンツ長許容されるべきである[2] IMPLICIT INTEGER（0..ubコンテンツ長）OPTIONAL、
-- Security features security [3] IMPLICIT SecurityElement OPTIONAL };
- セキュリティは、セキュリティがあります[3] IMPLICIT SecurityElement OPTIONAL}。
Restrict
制限します
This argument indicates whether the controls on ES-OPERATIONS are to be updated or removed. It may be generated by the EMSD-SA.
この引数は、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-操作を示します。これは、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は/送信ES-操作を起動してもしなくてもよいです。そして
o Other ES-OPERATIONS are not subject to controls, and may be invoked at any time.
他ESオペレーション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-操作は変更されません。
Permissible-max-content-length
許容-MAX-コンテンツ長
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が提出ES-操作によって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、 "SecurityElements" を参照してください。
Results
結果
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によって保持されているES-動作を示し、それは支配的なコントロールがなかった場合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は/メッセージを保持していないし、これは現行のコントロールがなければ提出ES-オペレーションを呼び出します。
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 ES-操作がEMSD-UAは、その提出の結果を受けているかどうかを確認するためにEMSD-SAを可能にします。
submissionVerify ES-OPERATION
submissionVerify ES-OPERATION
ARGUMENT SubmissionVerifyArgument
RESULT SubmissionVerifyResult
ERRORS
{
submissionVerifyError,
resourceError,
protocolViolation
} ::= 6;
The duplicate operation detection is not required for this operation.
重複操作の検出は、この操作は必要ありません。
Arguments
引数
This operation's arguments are:
この操作の引数は次のとおりです。
SubmissionVerifyArgument ::= SEQUENCE
-- 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 };
- このメッセージの識別子。提出結果に元に提供された - これは、同じ識別子です。 - 、メッセージ識別子の割り当てに関するコメントを参照してください - EMSDMessageIdの定義で。 {メッセージ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
};
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
{ credentials Credentials, contentIntegrityCheck ContentIntegrityCheck OPTIONAL };
{クレデンシャルクレデンシャル、contentIntegrityCheck ContentIntegrityCheck OPTIONAL}。
Credentials ::= CHOICE
{
simple [0] IMPLICIT SimpleCredentials
-- Strong Credentials are for future study -- strong [1] IMPLICIT StrongCredentials -- externalProcedure [2] EXTERNAL };
- 強力な[1] IMPLICIT StrongCredentials - - 強力な資格は、将来の研究のためのものであるexternalProcedure [2]外部}。
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);
Small messages can benefit from the efficiencies of connectionless feature of ESROS (See Efficient Short Remote Operations, RFC-2188 [1]).
小さなメッセージは、（[1] RFC-2188、効率的なショートリモート操作を参照してください）ESROSのコネクションレス機能の効率性の恩恵を受けることができます。
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, then use of the segmenting/reassembly mechanism introduced in this section is not necessary. This feature is accommodated in this layer by:
メッセージは、単一のコネクションPDUに収まるには大きすぎるが、接続確立のオーバーヘッドを正当化するのに十分な大きさでない場合は、ESROSのコネクションサービスが使用されている間、セグメント化と再組み立てされるメッセージのために、より効率的かもしれません。根底にあるリモート操作サービスはコネクションレス超える効率的なセグメンテーション/再構築（CL）サービスが可能な場合は、このセクションで紹介分割/再構築メカニズムの使用は必要ありません。この機能は、することによって、この層内に収容されています。
SegmentInfo ::= CHOICE
{ first [APPLICATION 2] IMPLICIT FirstSegment, other [APPLICATION 3] IMPLICIT OtherSegment };
{最初の[適用例2] IMPLICIT FirstSegment、他の[適用例3] IMPLICIT OtherSegment}。
FirstSegment ::= SEQUENCE
{
sequence-id INTEGER,
number-of-segments INTEGER
-- number-of-segments must not exceed ub-total-number-of-segments
};
OtherSegment ::= SEQUENCE
{
sequence-id INTEGER,
segment-number INTEGER
};
Segmentation and reassembly only applies to Message-submission and Message-delivery.
セグメンテーションと再組み立てはメッセージの提出とメッセージ配信に適用されます。
The sender of the message is responsible for segmenting the message content into segments that fit in CL PDUs. The segmented content is sent in a sequence of message-segments each carrying a segment of the content. sequence-Id is a unique identifier that is present in all message-segments. In addition to sequence identifier, the first message-segment specifies the total number of segments (number-of-segments). Other message-segments have a segment sequence number (segment-number). The receiver is responsible for sequencing (based on segment-number) and reassembling the entire message.
メッセージの送信者は、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.
シーケンス内のすべてのメッセージセグメントは、送信者によってシーケンス識別子を割り当てなければなりません。シーケンス識別子は、完全なメッセージシーケンスの送信後に送信者によってインクリメントされなければなりません。
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).
最初のメッセージセグメントは、セグメントの総数を指定します。最初のもの以外のシーケンス内のすべてのメッセージセグメントは、順次（最初のメッセージセグメントは、0の暗黙のセグメント番号を有する）1から始まる番号を付けなければなりません。
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-操作を発行することにより送信されます。セグメント化されたメッセージのすべてのセグメントは、同じ配列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.
任意のメッセージセグメント含量はコネクションレス伝送のためESROSによって許容される最大長さである必要はありません。しかしながら、-総数のセグメント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とは対照的に）FAILURE.indicationを受信した場合、メッセージ全体を再送信しなければなりません。
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.
受信機は、メッセージセグメントのために受信FAILURE.indicationsを無視し、単にメッセージを完了するために、メッセージ・セグメントを収集します。しかし、それはメッセージのいずれかのセグメントがFAILURE.indicationを受信した場合と言うセグメント化されたメッセージのために、障害の状態を保持します。受信機は、メッセージの状態は、メッセージセグメントのいずれかのためにFAILURE.indicationられている示している場合、その後、全セグメント化されたメッセージを組み立てるために成功した場合、そのメッセージが通過ベリファイ動作を検証します。送信者が前のセグメントの結果を待たずにセグメントを送信することがありますので、それはちょうど最後のメッセージセグメントに基づいて動作を確認呼び出すことは十分ではありません。このような場合には、送信側のメッセージ・セグメントの成功と失敗のいずれかの組み合わせがあるかもしれません。
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).
受信機は、全てのセグメント（全メッセージ）の再送信を要求する（セクション3.4.3を参照）エラーコードResourceErrorを使用する（セクション3.4.3を参照）は、単一セグメントの再送を要求すると、エラーコードMessageErrorを使用します。
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;
submissionControlViolated ERROR PARAMETER NULL ::= 2;
messageIdentifierInvalid ERROR PARAMETER NULL ::= 3;
securityError ERROR PARAMETER security-problem SecurityProblem ::= 4;
deliveryControlViolated ERROR PARAMETER NULL ::= 5;
resourceError ERROR PARAMETER NULL ::= 6;
protocolViolation ERROR PARAMETER NULL ::= 7;
messageError ERROR PARAMETER NULL ::= 8;
SecurityProblem ::= INTEGER (0..127); protocolVersionNotRecognized
The major and minor protocol versions presented do not match those recognized as being valid.
提示メジャーとマイナープロトコルバージョンは有効なものとして認識されるものと一致していません。
submissionControlViolated
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
メッセージ識別子が無効です。
The Message Identifier Invalid error reports that the Message Identifier presented to the MTS is not considered valid.
メッセージ識別子が無効です。エラーはメッセージ識別子がMTSに提示が有効と見なされていないことを報告します。
securityError
例外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
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
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
protocolViolation
Indicates that one or more mandatory argument(s) were missing.
一つ以上の必須の引数（s）が欠落していたことを示します。
messageError
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
-- Content types between 32 and 63 (inclusive) are for -- message types defined within this specifications. emsd-interpersonal-messaging-1995 (32), voice-messaging (33) -- reserved
- この仕様の範囲内で定義されたメッセージタイプ - 32と63との間のコンテンツタイプ（包括的）のためのものです。 EMSD-対人メッセージング1995年（32）、ボイスメッセージ（33） - 予約
-- Content types beyond and including 64 are for -- bilaterally-agreed use between peers. } (0..127);
- ピア間の二国間合意の使用 - 64を含むコンテンツの種類を超えたとはのためのものです。 }（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ドメイン内に発信された場合、この識別子は、EMSD-SAは、このIDを生成するために一意でなければなりません。
EMSDMessageId ::= CHOICE
{
EMSDLocalMessageId [APPLICATION 4]
IMPLICIT EMSDLocalMessageId,
rfc822MessageId [APPLICATION 5] IMPLICIT AsciiPrintableString (SIZE (0..ub-message-id-length)) };
rfc822MessageId [適用例5] IMPLICIT AsciiPrintableString（SIZE（0..ubメッセージ-IDの長さ））}。
EMSDLocalMessageId ::= SEQUENCE
{
submissionTime DateTime,
messageNumber INTEGER (0..ub-local-message-nu)
};
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で表現されています。 rfc822Domainは、任意の受信者に対処するために使用することができます。
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] IMPLICIT OCTET列（SIZE（0..ub-EMSD名長））OPTIONAL}。
Originator and Recipients in the scope of EMSD network are identified by a digit based addressing scheme. EMSDAddress can only be used where the scope of addressing has clearly been limited to the EMSD network.
EMSDネットワークの範囲内の発信者と受信者が数字ベースアドレススキームによって同定されます。アドレッシングの範囲が明確EMSDネットワークに限られていた場合EMSDAddressにのみ使用することができます。
DateTime ::= INTEGER;
DateTime is a Julian date, expressed as the number of seconds since 00:00:00 UTC, January 1, 1970.
日時は、ユリウス暦の日付である00:00:00 UTC、1970年1月1日からの秒数で表されます。
Iso8859String ::= GeneralString;
AsciiPrintableString ::= [APPLICATION 0]
IMPLICIT Iso8859String (FROM
(" "|"!"|"#"|"$"|"%"|"&"|"'"|"("|")"|"*"|"+"|","|"-"|"."|"/"|
"0"|"1"|"2"|"3"|"4"|"5"|"6"|"7"|"8"|"9"|":"|";"|"<"|"="|">"|
"?"|"@"|"A"|"B"|"C"|"D"|"E"|"F"|"G"|"H"|"I"|"J"|"K"|"L"|"M"|
"N"|"O"|"P"|"Q"|"R"|"S"|"T"|"U"|"V"|"W"|"X"|"Y"|"Z"|"["|"]"|
"^"|"_"|"`"|"a"|"b"|"c"|"d"|"e"|"f"|"g"|"h"|"i"|"j"|"k"|"l"|
"m"|"n"|"o"|"p"|"q"|"r"|"s"|"t"|"u"|"v"|"w"|"x"|"y"|"z"|"{"|
"|"|"}"|"~"|"\"|""""));
ProtocolVersionNumber ::= [APPLICATION 1] SEQUENCE
{
version-major INTEGER,
+------------------+-------+----+---------+----+---------+-----+-----+
|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] IMPLICIT整数デフォルト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).
提出操作の意味は、必ず1回です。正確に一度の操作はこれ以上と劣らず、正確に1回行われていないことを意味しません。この操作を呼び出した後、呼び出しが成功（例えば結果）表示とパフォーマーはFAILURE.indicationを持っており、ネットワークがダウンした場合、演算の結果はゼロになります、ので、セマンティックを完全に実施することができません（とない必ず1回）。
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.
ゼロではないが、1つはSubmissionVerify操作を使用して演奏することによって実現されます。パフォーマーがFAILURE.indicationを受信すると、それの責任はない、ゼロが、1つの結果としてSubmissionVerifyを使用してケースを解決することです。
Submission procedure is as follows:
次のように提出手順は次のとおりです。
o Submit operation with 3-Way handshake and Duplicate Operation Detection Support Function is invoked.
O 3ウェイハンドシェイクを使用して操作を提出し、重複した操作検出サポート機能が呼び出されます。
o If performer at EMSD-SA receives FAILURE.indication, it invokes SubmissionVerify.
EMSD-SAでのパフォーマーがFAILURE.indicationを受信した場合、O、それは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によって送出されるか、または動作（FAILURE.indicationの場合に）検証されます。
The semantic of SubmissionVerify operation is At Least Once. This type of semantics corresponds to the case that invoker keeps trying over and over until it gets a proper reply. This operation can be performed more than once without any harm.
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).
お届け操作の意味は、必ず1回です。正確に一度の操作はこれ以上と劣らず、正確に1回行われていないことを意味しません。このセマンティックは完全に実装することができない、操作を呼び出した後、呼び出しが成功指示があり、パフォーマーがFAILURE.indicationがあり、ネットワークがダウンした場合、演算の結果がゼロ（とは必ず1回）となります。
No more than one is controlled and guaranteed by performer and by using the Duplicate Operation Detection Support Functions.
1は、演奏者と重複する操作検出サポート機能を使用することによって制御され、保証されているに過ぎません。
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.
ゼロではないが、1つはDeliveryVerify操作を使用して演奏することによって実現されます。パフォーマーがFAILURE.indicationを受信すると、そうではない、ゼロになるが、1つDeliveryVerifyを使用してケースを解決する責任があります。
Delivery procedure is as follows:
次のように配信手順は次のとおりです。
o Deliver operation with 3-Way handshake is invoked.
3ウェイハンドシェイクが呼び出されると、Oの動作を提供します。
o If performer at User Agent (device) receives FAILURE.indication, it invokes DeliveryVerify.
ユーザーエージェント（デバイス）のパフォーマーがFAILURE.indicationを受信した場合、O、それは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.
UA oを配信レポートが送信されていることを確認する（明示的なdeliveryVerify経由）MTSに通知する責任があります。
4 DUPLICATE OPERATION DETECTION SUPPORT
4 DUPLICATE操作検出SUPPORT
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.
重複検出のためのサポートは、呼び出しの操作に（セクション4.1.2、「操作インスタンス識別子」を参照）の操作インスタンスIDを割り当てることにより実現されます。動作は重複検出サポートを使用して呼び出されると、演奏操作インスタンス識別子を記録し、複製に対して次の操作をチェックします。
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.
演算値は、2つのグループに分かれています。 32 63から0から31までの操作値（0〜31）重複操作検出サポートしていないと動作値が重複操作の検出をサポートしています。
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オペレーションインスタンス識別子は1バイトであり、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ビットであるが、演奏者の能力に応じて、それが重複検出用の127件の操作インスタンス識別子に0を維持するかもしれません。パフォーマーのプロフィールは重複と照合され、優れた操作インスタンス識別子の数を定義します。パフォーマーのプロフィールは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チェックは、それ自体ESROS、の一部ではありません。重複検出の使用は、EMSD-Pによって決定されます。操作32-63のためのオペレーションインスタンスIDは、引数の最初のバイトです。重複の検出は、そのバイトストリップをsuuport。
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それはuniqelyと明確に操作を特定の方法で操作インスタンス識別子を選択するユーザーの責任です。
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呼び出しの観点から、仮定は、同じ操作インスタンス識別子を有する2つの操作は、それらが全く同じ結果を生成意味し、完全に同一であるということです。
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オペレーションインスタンス識別子はuniqely重複インスタンスが識別され、動作が複数回行われていないため、このような動作の非冪等の操作と複数の呼び出しが最終的に同じ結果をもたらすであろう特定します。
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演奏者の視点から、仮定は同じオペレーションインスタンス識別子を持つ2つの操作は1回のみ実行されなければならないということです。
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 EMSDの手順
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.
以下のセクションでそれらをサポート操作上の3ウェイまたは2ウェイハンドシェイクのためのオプションを有するEMSDメッセージ転送サーバ（MTS）及びEMSDユーザエージェント（UA）の実装に使用される一般的な手順を示しています。これらの手順は、実装のための完全な動作仕様を構成するものではありません。次のセクションでは、実装者に役立つ情報が含まれています。
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:
それはESROSからイベントを受信した場合、それは次のタイプのいずれかが考えられます。
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 DeliveryVerify指示;
o Result and Error indication for a submissionVerify operation;
O結果とsubmissionVerify操作のためのエラー表示。
o Result and Error indication for a submissionControl operation;
O結果とsubmissionControl操作のためのエラー表示。
o DeliveryControl indication.
delivarikantrol表示をああ。
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;
RFC-822メーラからのメッセージ配信のためのO;
o requesting submission controls upon the UA, or;
UA時に提出のコントロールを要求して、O、または;
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のパフォーマーはESROSから受け取った次の操作を処理するための責任があります：
o Message-submission
Oメッセージ-提出
o Delivery-control o Delivery-verify
O配信制御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タイプに送り返されます。
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のパフォーマーはESROSから有効なイベントを受信しました。これは、定義された提出し、配信プロトコル動作のいずれかである可能性があります。
1. The Message-submission operation first checks to see which SAP
this Submit Request came in on.
2. The request could have arrived as 2-Way SAP (see #3) or a 3-Way SAP (see #7).
2.要求は（＃7を参照）2ウェイのSAP（＃3を参照）または3ウェイのSAPとして到着した可能性があります。
3. If the event arrived on the 2-Way SAP, consider this a protocol violation and ignore it.
3.イベントは、2ウェイの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. ERROR.requestが確認されています。 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.
ErrorRequestの結果がFailure.indication場合6.は、UAのいずれかがUAの障害を意味し、（ERROR.request PDUが失われた）何も受信しなかったと仮定することができます。または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.
イベントは3ウェイのSAP上で受信された場合7.、これは送信要求を受信する上で正しい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を参照）のいずれかであろう。
11. Attempt, a number of times, to send the submitted message via the RFC-822 mailer. If the send was successful, then return.
RFC-822メーラーを介して送信メッセージを送信する11試み回数。送信が成功した場合、戻ります。
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. IFが、最大再試行回数の後、メッセージが送信できませんでした、それは失敗を検討してください。 UAの仮定は、その提出が成功したされたが、今それが送信されていないので、ブランドの新しいメッセージ、配信不能メッセージは、UAに生成され、送達されなければなりません。これが完了すると、その後、戻ります。
13. A FAILURE.indication has occurred due to the previously issued RESULT.request.
13. A FAILURE.indicationが原因以前に発行されたRESULT.requestに発生しています。
14. A Submission Verification is issued to the UA to see if the RESULT.request was received. There are three possible results from sending the submission verification to the UA: Fail (see #15), Send Message (see #16) or Drop Message (see #20).
14. A提出の検証はRESULT.requestが受信されたかどうかを確認するためにUAに対して発行されます。失敗（＃15を参照）、メッセージを送信する（＃16を参照）またはドロップメッセージ（＃20を参照してください）：UAに提出検証を送信から3つの可能な結果があります。
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.
RFC-822メーラーを介して送信メッセージを送信する17試み回数。
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は、それがメッセージIDを受信していないので、メッセージが送信できなかったことをユーザに通知しなければならなかったんことを意味し、MTSからの結果を受けたことがない場合、これが発生することがあります。 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は、以前に配信されたメッセージからRESULT.indicationを受信したことを考えていないときに、この操作が発生します。 UAは、MTSは、それが配信されている知っていることを確認したいと考えています。 MTSは、それが指定されたメッセージを知っているかを判断し、その結果を送り返します。それは重複検出に対処する必要はありませんので、これは、すぐに処理することができます。
The MTS invoker is responsible for processing the following operations, received from ESROS:
MTSの呼び出しがESROSから受け取った次の操作を処理するための責任があります：
o Message-delivery
Oメッセージ配信
o Submission-control
O提出制御
o Submission-verify
O提出-検証
Submission-control
提出制御
Process the Submission Control request.
提出制御要求を処理します。
Message-delivery
メッセージ配信
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).
ERROR.indication（＃5を参照）、RESULT.indication（＃9を参照）またはFAILURE.indication（＃10を参照）。4. INVOKE.requestの結果の可能な三つの可能なイベントがあります。
5. An ERROR.indication was received, which means that the UA can't accept the message right now.
5.アンERROR.indicationは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. A RESULT.Indicationは配達が成功したことを意味し、返されました。 1が要求された場合は、発信者に配信レポートを送信し、正常な配信とリターンを記録します。
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プロファイルは完全なモードが使用されることになっていた、UAが私たちを送信した場合の配信は、動作を確認しているように、このメッセージが正常に、（限りMTSが懸念しているとして）配信されたという事実を追跡することが示された場合、我々はそれを知っています私たちは、メッセージが配信されると考えています。
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. A 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.
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.
提出ベリファイは常に2ウェイの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.無効重複検出で、2ウェイの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が発行され、応答が受信されています。応答はRESULT.indication（＃3を参照）またはFAILURE.indication（＃4を参照）のいずれかであろう。そうERROR.indicationが、ここで発生するべきではありません提出を確認し、操作への定義されたエラーは、ありません。
3. A RESULT.indication was received. Either ResponseSendMessage or ResponseDropMessage, as specified in the PDU, will be returned.
3. A RESULT.indicationを受信しました。 ResponseSendMessageまたはResponseDropMessageのいずれかが、PDUに指定されているように、返されます。
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. A 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を発行します。この操作は、常に2ウェイのSAPに発行されます。応答を待ちます。応答が来ない場合は、要求がキューに入れられ、後で再試行されます。
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 2.発行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に対する応答が受信されています。応答はRESULT.indication（＃5を参照）、ERROR.indication（＃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.アンERROR.indicationは、UAは、当社の配信不能レポートで何をすべきかわからないことを意味し、受信しました。それはこれだけ何もして復帰しない、のUAの問題です。
5. A RESULT.indication was received, which means we delivered a successful non-delivery report.
5. A RESULT.indicationは、我々は成功し、配信不能レポートをお届け意味し、受信しました。
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. A 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:
それはESROSからイベントを受信した場合、それは次のタイプのいずれかが考えられます。
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
メッセージ配信
2. Check for the correctness of the PDU. If the PDU is bad the see #3. If the PDU is good then see #8.
PDUの正確性について2.チェック。 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を使用しています。要求は2ウェイのSAPに到着した場合は、結果のために2ウェイのSAPを使用しています。発行された要求の種類を追跡します。
4. Wait for the ESROS event. The result could be an ERROR.confirm (see #5) or a FAILURE.indication (see #7).
4. ESROSイベントを待ちます。結果はERROR.confirm（＃5を参照）またはFAILURE.indication（＃7を参照）とすることができます。
6. Log the message as the Non-Delivery was confirmed by the MTS and return.
配信不能がMTSと戻りによって確認されたとして6メッセージをログに記録します。
7. If the ESROS event was a FAILURE.indication, that means one of two things has occurred:
7. ESROSイベントは、2つのうちの1つが発生したことを意味し、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は、MTSは、メッセージの配信が拒否されたことを知らないことを意味し、（ERROR.request PDUが失われた）何も受信していません。この場合、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. 3ウェイの確認はMTSが実際にERROR.request 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を使用しています。要求は2ウェイのSAPに到着した場合は、結果のために2ウェイの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.
イベントがRESULT.confirm場合10は、その後、配信されたメッセージは、現在のユーザに与えることができます。
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.
イベントはFAILURE.indicationであれば配達は3ウェイのSAPにあった場合は13、そして、MTSへの配達確認要求がMTSが実際にRSULT.requestを得たかどうかを確認するために発行することができます。配信は2ウェイの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.
UAが配信検証をサポートし、配信要求は3ウェイのSAPに送信された場合は16、その後、＃17を参照してください。これらの条件のいずれかが真でない場合、戻ります。
17. Send a Delivery-verify request to see if the MTS got the RESULT.request.
17. MTSはRESULT.requestを得たかどうかを確認するために配達-検証要求を送信します。
There are three possible results from sending the delivery
verification to the MTS: Fail (see #18), ResponseNonDelivery
(see #20) or ResponseDelivery (see #23).
18. Fail -- Delivery Verify request didn't reach the MTS, or the Delivery Verify response didn't get back to the UA.
18.フェイル - 配達バックUAに取得していない応答を確認しMTSに到達しなかった要求を確認し、または配達。
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.
ユーザーにメッセージを配信するが、MTSはおそらく持つように19.ログインこれは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 - メッセージがユーザーに配信されてきたが、私たちのRESULT.requestを受けず配信がタイムリーで動作を確認していなかった、と持っていたという動作を確認しので、配達の（レスポンス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 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.
21. MTSは、適時に、RESULT.indicationメッセージがユーザに配信されたことを示し、UAから、受信していませんでした。 MTSは、すでに元に配信不能レポートを送信しました。 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を削除することができます。
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によって送信されたか、MTSが今UAはに配信するためのメッセージを受け取ったことを知らせる、UAの配信検証メッセージを受信したため、RESULT.requestを受けていたので、ユーザーはMTSは1が要求された場合、発信者に配信レポートを送信することができます（またはあった）。そのようにログインします。
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.
3ウェイのSAP 1.発行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を発行しています。 ESROSからの応答を待ちます。応答は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. A ERROR.indicaitonはMTSは、それがメッセージを受け入れることができないと言う話したことを意味し、受信されました。
5. A RESULT.indication was received, which means that the Submission was successful.
5. A RESULT.indicationは提出が成功したことを意味し、受信しました。
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.
MTSの提出・確認することをUAの配信-検証鏡のための一般的な手順。
6 EMSD FORMAT STANDARDS
6つのEMSDフォーマット規格
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.
「OPTIONAL」（O）、（D）「DEFAULT」、（C）「条件」と情報の存在のための要件を表す（M）「必須」の慣例は、このセクションで使用されています。
An interpersonal message (IPM) consists of a heading and a body.
個人間メッセージ（IPM）は、見出しと本体から成ります。
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,
-- Address of the originator of the message -- (not necessarily the sender) originator EMSDORAddress,
- メッセージの発信者のアドレス - （必ずしも送信者）発信EMSDORAddress、
-- List of recipients and flags associated with each. recipient-data SEQUENCE SIZE (1..ub-recipients) OF PerRecipientFields,
- それぞれに関連付けられた受信者およびフラグのリスト。 PerRecipientFieldsの受け手データシーケンスSIZE（1..ub-受信者）
-- Flags applying to this entire message per-message-flags [1] IMPLICIT BIT STRING
- この全体のメッセージごとのメッセージ・フラグ[1] IMPLICITビット列に適用するフラグ
{ -- 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),
{ - 優先値 - 「非緊急」の最大1つおよび「緊急」が指定されてもよい - 並行。どちらも指定されている場合は、優先順位 - 「通常」のレベルが想定されます。優先非緊急（0）、優先度緊急（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),
- 同時に - 「低」と「高」のほとんど1で指定することができます。どちらも指定されていない場合は、 - 「通常」の重要度が想定されます。重要度の低い（2）、重要度の高い（3）、
-- Indication of whether this message has been automatically forwarded auto-forwarded (4) } OPTIONAL,
- このメッセージは自動的に自動転送（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,
- このメッセージへの返信を受信することで、ユーザーが指定した受信者。返信-にEMSDORAddress OPTIONAL [2] IMPLICIT SEQUENCEサイズ（1..ub-返信します）、
-- Identifier of a previous message, for which this message -- is a reply replied-to-IPM EMSDMessageId OPTIONAL,
- は、このメッセージ以前のメッセージの識別子 - 応答返信ツーIPMさEMSDMessageId OPTIONAL、
-- Subject of the message. subject [3] IMPLICIT AsciiPrintableString (SIZE (0..ub-subject-field)) OPTIONAL,
- メッセージの件名。被験体[3] IMPLICIT AsciiPrintableString（SIZE（0..ub-サブジェクトフィールド））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,
- RFC-822明示的にするために設けられていないヘッダーフィールド - この見出し。外部からの着信メッセージについて - （すなわち、RFC-822形式の）世界、メッセージ-ID：エンベロープのEMSDMessageId（メッセージID）フィールド - フィールドには、 - それが中に配置されたとして必要、ここでは行きません。 IPMSExtension OPTIONALの延長[4] IMPLICIT SEQUENCE（SIZE（0..ub-ヘッダ拡張））、
-- MIME Version (if other than 1.0) mime-version [5] IMPLICIT AsciiPrintableString (SIZE (0..ub-mime-version-length)) OPTIONAL,
- MIMEバージョン（1.0以外の場合）MIMEバージョン[5] IMPLICIT AsciiPrintableString（SIZE（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] IMPLICIT AsciiPrintableString（SIZE（0 .. UB-MIMEコンテンツタイプ - 長さ））OPTIONAL、
-- MIME Content Id mime-content-id [7] IMPLICIT AsciiPrintableString (SIZE (0.. ub-mime-content-id-length)) OPTIONAL,
- MIMEコンテンツイド、MIMEコンテンツID [7] IMPLICIT AsciiPrintableString（SIZE（0 .. UB-、MIMEコンテンツIDの長さ））OPTIONAL、
-- MIME Content Description mime-content-description [8] IMPLICIT AsciiPrintableString (SIZE (0..ub-mime-content-description-length)) OPTIONAL, -- Top-level MIME Content Type mime-content-transfer-encoding
- MIMEコンテンツ記述MIMEコンテンツ記述[8] IMPLICIT AsciiPrintableString（SIZE（0..ub-MIMEコンテンツ記述長））OPTIONAL、 - トップレベルMIMEコンテンツタイプMIMEコンテンツ転送エンコード
[9] IMPLICIT AsciiPrintableString (SIZE (0..ub-mime-content-transfer-encoding)) OPTIONAL };
[9] IMPLICIT AsciiPrintableString（SIZE（0..ub-MIMEコンテンツ転送エンコード））OPTIONAL}。
Some fields have components and thus are composite, rather than indivisible. A field component is called a sub-field.
一部のフィールドは、コンポーネントを持っているので、複合、というよりも不可分です。磁界成分は、サブフィールドと呼ばれます。
Sender
送信者
This field is mandatory if the sender is different from the originator.
送信者が発信元と異なっている場合、このフィールドは必須です。
Originator
元祖
The Originator heading field (O) identifies the IPM's originator.
オリジネーターの見出しフィールド（O）はIPMの発信元を特定します。
Recipient-data
受信者データ
PerRecipientFields ::= SEQUENCE
{
recipient-address EMSDORAddress,
per-recipient-flags BIT STRING
{ -- Recipient Types. -- At most one of "copy" and "blind-copy" may be -- specified concurrently for a single recipient. If -- neither is specified, than the recipient -- is assumed to be a "primary" recipient. recipient-type-copy (0), recipient-type-blind-copy (1),
{ - 受信者の種類。 - 「コピー」と「ブラインドコピー」の最も1にすることができる - 単一の受信者のために同時に指定されています。どちらも指定されていない、受信者より - - 場合は、「プライマリ」の受信者を想定しています。レシピエント型コピー（0）、受信者型ブラインドコピー（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),
- 通知要求タイプ。 - 「RN」との唯一の「NRN」に指定することができる - 同時に、\単一の受信者のためのx110011。 - "RNは" ほかに "NRN" を意味します。通知要求RN（2）、通知要求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),
- 特定の受信者 - これらの最大1つはのために設定する必要があります。加えて - 「送達」、「配信不能」を意味します。レポート要求非配信（5）、レポート要求配信（6）、
-- Originator-to-Recipient request for a reply. reply-requested (7) } DEFAULT { report-request-non-delivery }
- 返信用オリジネータ・ツー・受信者の要求。返信要求（7）} DEFAULT {レポート要求配信不能}
};
｝；
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.
コピー受信者フィールド見出しは、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
通知要求-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
通知要求-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-ユーザーにメッセージ-提出またはプローブ-提出抽象オペレーションの前の呼び出しの1つの以上の成果を確認するために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.
メッセージの提出については、レポートの配信は、配信または1人のまたは複数の受信者に送信したメッセージの配信不能を示します。プローブの提出については、レポートの配信は、メッセージが送信されるならば、メッセージが配信される可能性があるか否かを示します。
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.
Priorityフィールド（デフォルトは正常です）許可ユーザーは、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.
ほとんどのいずれかで「非緊急」の1または「緊急」は、同時に指定することができます。どちらも指定されている場合は、「通常」の優先レベルを想定しています。
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.
「低」または「高」のいずれかの最大1つは、同時に指定することができます。どちらも指定されている場合は、「通常」の重要度が想定されます。
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
};
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.
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. };
メッセージボディのオクテットSTRING - ボディの構造のためのMIMEを参照してください。圧縮方式が指定されている場合、テキスト全体を含む - - のContent-Type：RFC-822本体に続く要素は、 - 指定されたメソッドを使用して圧縮され、そして本明細書中に置きました。 }。
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)
- 64と127の間番号圧縮方法であってもよい - ピア間左右合意に基づいて使用されます。 }（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と協定ナローバンドPCSの上に、AT＆Tワイヤレスサービス（AWS）上の限定サイズメッセージング（LSM）の文脈では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
モフセン・バナンネダコミュニケーションズ株式会社17005 SE 31位ベルビュー、WA 98008
EMail: mohsen@neda.com
メールアドレス：mohsen@neda.com
A EMSD-P ASN.1 MODULE
EMSD-P ASN.1 MODULE
This section compiles in one place the complete ASN.1 Module for EM Submission and Delivery Protocol.
このセクションでは、一つの場所にEM提出し、配信プロトコルのための完全なASN.1モジュールをコンパイルします。
EMSD-SubmissionAndDeliveryProtocol DEFINITIONS ::=
BEGIN
ベギン
EXPORTS EMSDORAddress, AsciiPrintableString, ContentType, DateTime, EMSDMessageId, EMSDORAddress, ProtocolVersionNumber;
EXPORTS EMSDORAddress、AsciiPrintableString、ContentTypeを、日時、EMSDMessageId、EMSDORAddress、ProtocolVersionNumber。
-- Upper bounds
- 上限
ub-recipients INTEGER ::= 256;
-- also defined in EMSD-InterpersonalMessaging1995
ub-reply-to INTEGER ::= 256;
-- also defined in EMSD-InterpersonalMessaging1995
ub-subject-field INTEGER ::= 128;
-- also defined in EMSD-InterpersonalMessaging1995
ub-password-length INTEGER ::= 16;
ub-content-length INTEGER ::= 65535;
-- also defined in EMSD-Probe
ub-content-types INTEGER ::= 128;
ub-message-id-length INTEGER ::= 127;
ub-total-number-of-segments INTEGER ::= 32;
ub-header-extensions INTEGER ::= 64;
-- also defined in EMSD-InterpersonalMessaging1995
ub-emsd-name-length INTEGER ::= 64;
ub-emsd-address-length INTEGER ::= 20;
ub-rfc822-name-length INTEGER ::= 127;
ub-mime-version-length INTEGER ::= 8;
-- also defined in EMSD-InterpersonalMessaging1995
ub-mime-content-type-length INTEGER ::= 127;
-- also defined in EMSD-InterpersonalMessaging1995
ub-mime-content-id-length INTEGER ::= 127;
-- also defined in EMSD-InterpersonalMessaging1995
ub-mime-content-description-length INTEGER ::= 127;
-- also defined in EMSD-InterpersonalMessaging1995
ub-mime-content-transfer-encoding INTEGER ::= 127;
-- also defined in EMSD-InterpersonalMessaging1995
ub-local-message-nu INTEGER ::= 4096;
----------------------
-- SUBMIT Operation --
----------------------
submit ES-OPERATION
ES-OPERATIONを提出
ARGUMENT SubmitArgument
RESULT SubmitResult
ERRORS
{
submissionControlViolated,
securityError,
resourceError,
protocolViolation,
messageError
} ::= 33;
SubmitArgument ::= SEQUENCE
{
-- Security features
security [0] IMPLICIT SecurityElement
OPTIONAL,
-- Segmentation features for efficient transport segment-info SegmentInfo OPTIONAL,
- 効率的な輸送セグメント情報SegmentInfoオプションのためのセグメンテーション機能、
-- Content type of the message content-type ContentType,
- メッセージコンテンツタイプContentTypeをのコンテンツの種類、
-- -- THE CONTENT -- --
- - コンテンツ - -
-- The submission content content ANY DEFINED BY content-type
- ANYは、コンテンツタイプによって定義された申請内容のコンテンツ
};
｝；
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 };
- このメッセージの恒久的な識別子。 - また、メッセージの送信時間が含まれています。 - EMSDLocalMessageIdの定義では、識別子 - メッセージの割り当てに関するコメントを参照してください。メッセージID EMSDLocalMessageId}。
--------------------------------
-- Delivery Control Operation --
--------------------------------
deliveryControl ES-OPERATION
deliveryControl ES-OPERATION
ARGUMENT DeliveryControlArgument
RESULT DeliveryControlResult
ERRORS
{
securityError,
resourceError,
protocolViolation
} ::= 2;
DeliveryControlArgument ::= SEQUENCE
{
-- Request an addition of or removal of a set of restrictions
restrict [0] IMPLICIT Restrict DEFAULT update,
-- Which operations are to be placed in the restriction set permissible-operations [1] IMPLICIT Operations OPTIONAL,
- どの操作は、[1] IMPLICIT操作OPTIONAL許容オペレーションを設定する制限内に配置されます
-- What maximum content length should be allowed permissible-max-content-length [2] IMPLICIT INTEGER (0..ub-content-length) OPTIONAL,
- 最大どのようなコンテンツの長さが許容-MAX-コンテンツ長許容されるべきである[2] IMPLICIT INTEGER（0..ubコンテンツ長）OPTIONAL、
-- What is the lowest priority message which may be delivered permissible-lowest-priority [3] IMPLICIT ENUMERATED { non-urgent (0), normal (1), urgent (2) } OPTIONAL,
- 、[3] IMPLICIT ENUMERATED {非緊急（0）、通常（2）（1）、緊急} OPTIONAL許容-最低優先送達することができる最も低い優先度のメッセージは何ですか
-- Security features security [4] IMPLICIT SecurityElement OPTIONAL,
- セキュリティは、[4] IMPLICIT SecurityElementオプションのセキュリティを備え
-- User Feature selection user-features [5] IMPLICIT OCTET STRING OPTIONAL };
- ユーザ特徴選択ユーザー機能[5] IMPLICIT OCTET STRINGをOPTIONAL}。
DeliveryControlResult ::= SEQUENCE
{
-- Operation types queued at the EMSD-SA due to existing
-- restrictions.
waiting-operations [0] IMPLICIT Operations DEFAULT { },
-- Types of messages queued at the EMSD-SA due to -- existing restrictions waiting-messages [1] IMPLICIT WaitingMessages DEFAULT { },
- メッセージの種類に起因しEMSD-SAでキューに入れ - - メッセージ待機既存の制限[1] IMPLICIT WaitingMessagesデフォルト{}、
-- Content Types of messages queued at the EMSD-SA waiting-content-types SEQUENCE SIZE (0..ub-content-types) OF ContentType DEFAULT { } };
- メッセージのコンテンツタイプは、ContentTypeをデフォルト{}} OF EMSD-SAの待ちコンテンツタイプSEQUENCEサイズ（0..ubコンテンツ・タイプ）でキューに入れられました。
Restrict ::= ENUMERATED
{
update (1),
remove (2)
};
Operations ::= BIT STRING
{
submission (0),
delivery (1)
};
WaitingMessages ::= BIT STRING
{
long-content (0),
low-priority (1)
};
-- Delivery Verify Operation
- 配達ベリファイ
deliveryVerify ES-OPERATION
deliveryVerify ES-OPERATION
ARGUMENT DeliveryVerifyArgument
RESULT DeliveryVerifyResult
ERRORS
{
verifyError,
resourceError,
protocolViolation
} ::= 5;
DeliveryVerifyArgument ::= SEQUENCE
{
-- Identifier of this message. This is the same identifier that
-- was provided to the originator in the Submission Result.
-- See comment regarding assignment of message identifiers,
-- at the definition of EMSDMessageId.
message-id EMSDMessageId
};
DeliveryVerifyResult ::= SEQUENCE
{
status DeliveryStatus
};
DeliveryStatus ::= ENUMERATED
{
no-report-is-sent-out (1),
delivery-report-is-sent-out (2),
non-delivery-report-is-sent-out (3)
};
-----------------------
-- DELIVER Operation --
-----------------------
deliver ES-OPERATION
ARGUMENT DeliverArgument
RESULT NULL
ERRORS
{
deliveryControlViolated,
securityError,
resourceError,
protocolViolation,
messageError
} ::= 35;
DeliverArgument ::= SEQUENCE
{
-- Identifier of this message. This is the same identifier that
-- was provided to the originator in the Submission Result.
-- See comment regarding assignment of message identifiers,
-- at the definition of EMSDMessageId.
message-id EMSDMessageId,
-- Time the message was delivered to the recipient by EMSD-SA message-delivery-time DateTime,
- メッセージがEMSD-SAメッセージ配信時間のDateTimeによって受信者に配信された時刻、
-- Time EMSD-SA originally took responsibility for processing -- of this message. This field shall be omitted if the message-id -- contains an EMSDLocalMessageId, because that field contains -- the submission time within it. message-submission-time [0] IMPLICIT DateTime OPTIONAL,
- このメッセージの - 時間EMSD-SAは、元々の処理のための責任を取りました。提出時間をその中に - そのフィールドが含まれているため、EMSDLocalMessageIdが含まれています - メッセージIDがあれば、このフィールドは省略されなければなりません。メッセージ提出時間[0] IMPLICIT日時OPTIONAL、
-- Security features security [1] IMPLICIT SecurityElement OPTIONAL,
- セキュリティは、[1] IMPLICIT SecurityElementオプションのセキュリティを備え
-- SegContentTypementation features for efficient transport segment-info SegmentInfo OPTIONAL,
- 効率的な輸送セグメント情報SegmentInfoオプションについてSegContentTypementation機能、
-- 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;
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] IMPLICIT操作OPTIONAL許容オペレーションを設定する制限内に配置されます
-- What maximum content length should be allowed permissible-max-content-length [2] IMPLICIT INTEGER (0..ub-content-length) OPTIONAL,
- 最大どのようなコンテンツの長さが許容-MAX-コンテンツ長許容されるべきである[2] IMPLICIT INTEGER（0..ubコンテンツ長）OPTIONAL、
-- Security features security [3] IMPLICIT SecurityElement OPTIONAL };
- セキュリティは、セキュリティがあります[3] IMPLICIT SecurityElement OPTIONAL}。
SubmissionControlResult ::= SEQUENCE
{
-- Operation types queued at the EMSD-SA due to existing
-- restrictions. waiting-operations [0] IMPLICIT Operations DEFAULT { }
- 制限。待機動作[0] IMPLICITオペレーションDEFAULT {}
};
｝；
----------------------------------
-- Submission Verify Operation --
----------------------------------
submissionVerify ES-OPERATION
submissionVerify ES-OPERATION
ARGUMENT SubmissionVerifyArgument
RESULT SubmissionVerifyResult
ERRORS
{
submissionVerifyError,
resourceError,
protocolViolation
} ::= 6;
SubmissionVerifyArgument ::= SEQUENCE
-- Identifier of this message. This is the same identifier that
-- was provided to the originator in the Submission Result.
-- See comment regarding assignment of message identifiers,
-- at the definition of EMSDMessageId.
{
message-id EMSDMessageId
};
SubmissionVerifyResult ::= SEQUENCE
{
status SubmissionStatus
};
SubmissionStatus::= ENUMERATED
{
send-message (1),
drop-message (2)
};
-- GetConfiguration Operation -- To be fully defined later. This will possibly include, -- but not be limited to: -- get-local-time-zone -- get-protocol-version -- etc.
- GetConfiguration操作 - 完全に後に定義します。これはおそらく、含まれています - これらに限定されない： - 取得ローカル時間帯を - 取得・プロトコル・バージョンを - など
getConfiguration ES-OPERATION
getConfiguration ES-OPERATION
ARGUMENT NULL
RESULT NULL
ERRORS
{
resourceError,
protocolViolation
} ::= 7;
-- SetConfiguration Operation -- To be fully defined later.
- のSetConfiguration操作 - 完全に後に定義します。
setConfiguration ES-OPERATION
SetConfiguration ES-OPERATION
ARGUMENT NULL
RESULT NULL
ERRORS
{
resourceError,
protocolViolation
} ::= 8;
-- Security --
- セキュリティ -
SecurityElement ::= SEQUENCE
{ credentials Credentials, contentIntegrityCheck ContentIntegrityCheck OPTIONAL };
{クレデンシャルクレデンシャル、contentIntegrityCheck ContentIntegrityCheck OPTIONAL}。
Credentials ::= CHOICE
{
simple [0] IMPLICIT SimpleCredentials
-- Strong Credentials are for future study
-- strong [1] IMPLICIT StrongCredentials
-- externalProcedure [2] EXTERNAL
};
SimpleCredentials ::= SEQUENCE
{ eMSDAddress EMSDAddress OPTIONAL, password [0] IMPLICIT OCTET STRING (SIZE (0..ub-password-length)) OPTIONAL };
{eMSDAddress EMSDAddress OPTIONAL、パスワード[0] IMPLICIT OCTET列（SIZE（0..ubパスワード長））OPTIONAL}。
-- StrongCredentials ::= NULL
-- for now.
-- ContentIntegrityCheck is a 16-bit checksum of content
ContentIntegrityCheck ::= INTEGER (0..65535);
SegmentInfo ::= CHOICE
{ first [APPLICATION 2] IMPLICIT FirstSegment, other [APPLICATION 3] IMPLICIT OtherSegment };
{最初の[適用例2] IMPLICIT FirstSegment、他の[適用例3] IMPLICIT OtherSegment}。
FirstSegment ::= SEQUENCE
{ sequence-id INTEGER, number-of-segments INTEGER -- number-of-segments must not exceed ub-total-number-of-segments
{配列-IDのINTEGER、数のセグメントINTEGER - UB-総数のセグメントを超えてはならない数のセグメント
};
｝；
OtherSegment ::= SEQUENCE
{ sequence-id INTEGER, segment-number INTEGER };
{配列-IDのINTEGER、セグメント番号INTEGER}。
-----------
-- Errors --
------------
protocolVersionNotRecognized ERROR PARAMETER NULL ::= 1;
submissionControlViolated ERROR PARAMETER NULL ::= 2;
messageIdentifierInvalid ERROR PARAMETER NULL ::= 3;
securityError ERROR PARAMETER security-problem SecurityProblem ::= 4;
deliveryControlViolated ERROR PARAMETER NULL ::= 5;
resourceError ERROR PARAMETER NULL ::= 6;
protocolViolation ERROR PARAMETER NULL ::= 7;
messageError ERROR PARAMETER NULL ::= 8;
SecurityProblem ::= INTEGER (0..127);
-- -- EXPORTED Definitions (for use by associated specifications) -- --
- - （関連規格で使用するため）はエクスポート定義 - -
ContentType ::= INTEGER
{
-- Content type 0 is reserved and shall never be transmitted.
reserved (0),
-- Content types between 1 and 31 (inclusive) are for
-- internal-use only
probe (1), -- reserved
delivery-report (2), -- reserved
-- Content types between 32 and 63 (inclusive) are for -- message types defined within this specifications. emsd-interpersonal-messaging-1995 (32), voice-messaging (33) -- reserved
- この仕様の範囲内で定義されたメッセージタイプ - 32と63との間のコンテンツタイプ（包括的）のためのものです。 EMSD-対人メッセージング1995年（32）、ボイスメッセージ（33） - 予約
-- Content types beyond and including 64 are for -- bilaterally-agreed use between peers. } (0..127);
- ピア間の二国間合意の使用 - 64を含むコンテンツの種類を超えたとはのためのものです。 }（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.
そのメッセージからフィールド： - このメッセージは、RFC-822のメッセージとして発信された場合、この - EMSDMessageIdは、「メッセージID」でなければなりません。このメッセージは、EMSDドメイン内で発信された場合は、 - - このIDを生成 - この識別子は、メッセージセンターのためのユニークなものでなければなりません。
EMSDMessageId ::= CHOICE
{
emsdLocalMessageId [APPLICATION 4] IMPLICIT
EMSDLocalMessageId,
rfc822MessageId [APPLICATION 5] IMPLICIT
AsciiPrintableString
(SIZE (0..ub-message-id-length))
};
｝；
EMSDLocalMessageId ::= SEQUENCE
{
submissionTime DateTime,
messageNumber INTEGER (0..ub-local-message-nu)
};
-- An Originator/Recipient Address in EMSD Environment
- EMSD環境での発信/受信者のアドレス
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)),
-- 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アドレスはBCDで10進整数（バイナリエンコード進数）です。 - 左 - それは数字の奇数を持っていた場合、それが上の0で埋められます。
emsd-name [0] IMPLICIT OCTET STRING (SIZE (0..ub-emsd-name-length)) OPTIONAL };
EMSD名[0] IMPLICIT OCTET列（SIZE（0..ub-EMSD名長））OPTIONAL}。
DateTime ::= INTEGER;
Iso8859String ::= GeneralString;
AsciiPrintableString ::= [ APPLICATION 0 ]
IMPLICIT Iso8859String (FROM
(" "|"!"|"#"|"$"|"%"|"&"|"'"|"("|")"|"*"|"+"|","|"-"|"."|"/"|
"0"|"1"|"2"|"3"|"4"|"5"|"6"|"7"|"8"|"9"|":"|";"|"<"|"="|">"|
"?"|"@"|"A"|"B"|"C"|"D"|"E"|"F"|"G"|"H"|"I"|"J"|"K"|"L"|"M"|
"N"|"O"|"P"|"Q"|"R"|"S"|"T"|"U"|"V"|"W"|"X"|"Y"|"Z"|"["|"]"|
"^"|"_"|"`"|"a"|"b"|"c"|"d"|"e"|"f"|"g"|"h"|"i"|"j"|"k"|"l"|
"m"|"n"|"o"|"p"|"q"|"r"|"s"|"t"|"u"|"v"|"w"|"x"|"y"|"z"|"{"|
"|"|"}"|"~"|"\"|""""));
ProtocolVersionNumber ::= [APPLICATION 1] SEQUENCE
{
version-major INTEGER,
version-minor [0] IMPLICIT INTEGER DEFAULT 0
}
END -- end of EMSD-SubmissionAndDeliveryProtocol
B EMSD-IPM ASN.1 MODULE
B EMSD-IPM ASN.1 MODULE
This section compiles in one place the complete ASN.1 Module for EMSD-IPM.
このセクションでは、一つの場所にEMSD-IPMのための完全なASN.1モジュールをコンパイルします。
EMSD-InterpersonalMessaging1995 DEFINITIONS ::=
BEGIN
ベギン
IMPORTS EMSDORAddress, EMSDMessageId, AsciiPrintableString FROM EMSD-SubmissionAndDeliveryProtocol;
輸入EMSDORAddress、EMSDMessageId、EMSD-SubmissionAndDeliveryProtocol FROM 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;
IPM ::= SEQUENCE
{ heading Heading, body Body OPTIONAL };
{見出し見出し、本体ボディ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,
- メッセージの発信者のアドレス - （必ずしも送信者）発信EMSDORAddress、
-- List of recipients and flags associated with each. recipient-data SEQUENCE SIZE (1..ub-recipients) OF PerRecipientFields,
- それぞれに関連付けられた受信者およびフラグのリスト。 PerRecipientFieldsの受け手データシーケンスSIZE（1..ub-受信者）
-- Flags applying to this entire message per-message-flags [1] IMPLICIT BIT STRING
- この全体のメッセージごとのメッセージ・フラグ[1] IMPLICITビット列に適用するフラグ
{ -- 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),
{ - 優先値 - 「非緊急」の最大1つおよび「緊急」が指定されてもよい - 並行。どちらも指定されている場合は、優先順位 - 「通常」のレベルが想定されます。優先非緊急（0）、優先度緊急（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),
- 重要度 - 「低」と「高」の時に最大で1つを指定することが可能 - 同時に。どちらも指定されていない場合は、 - 「通常」の重要度が想定されます。重要度の低い（2）、重要度の高い（3）、
-- Indication of whether this message has been automatically -- forwarded auto-forwarded (4) } OPTIONAL,
転送自動転送（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,
- これに応答を受信することで、ユーザーが指定した受信者 - メッセージ。返信-にEMSDORAddress OPTIONAL [2] IMPLICIT SEQUENCEサイズ（1..ub-返信します）、
-- Identifier of a previous message, for which this message -- is a reply replied-to-IPM EMSDMessageId OPTIONAL,
- は、このメッセージ以前のメッセージの識別子 - 応答返信ツーIPMさEMSDMessageId OPTIONAL、
-- Subject of the message. subject [3] IMPLICIT AsciiPrintableString (SIZE (0..ub-subject-field)) OPTIONAL,
- メッセージの件名。被験体[3] IMPLICIT AsciiPrintableString（SIZE（0..ub-サブジェクトフィールド））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,
- RFC-822明示的にするために設けられていないヘッダーフィールド - この見出し。外部からの着信メッセージについて - （すなわち、RFC-822形式の）世界、メッセージ-ID：エンベロープのEMSDMessageId（メッセージID）フィールド - フィールドには、 - それが中に配置されたとして必要、ここでは行きません。 IPMSExtension OPTIONALの延長[4] IMPLICIT SEQUENCE（SIZE（0..ub-ヘッダ拡張））、
-- MIME Version (if other than 1.0) mime-version [5] IMPLICIT AsciiPrintableString (SIZE (0..ub-mime-version-length))
- MIMEバージョン（1.0以外の場合）MIMEバージョン[5] IMPLICIT AsciiPrintableString（SIZE（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] IMPLICIT AsciiPrintableString（SIZE（0 .. UB-MIMEコンテンツタイプ - 長さ））OPTIONAL、
-- MIME Content Id mime-content-id [7] IMPLICIT AsciiPrintableString (SIZE (0.. ub-mime-content-id-length)) OPTIONAL,
- MIMEコンテンツイド、MIMEコンテンツID [7] IMPLICIT AsciiPrintableString（SIZE（0 .. UB-、MIMEコンテンツIDの長さ））OPTIONAL、
-- MIME Content Description mime-content-description [8] IMPLICIT AsciiPrintableString (SIZE (0.. ub-mime-content-description-length)) OPTIONAL,
- MIMEコンテンツ記述MIMEコンテンツ記述[8] IMPLICIT AsciiPrintableString（SIZE（0 .. UB-MIMEコンテンツ記述長））OPTIONAL、
-- Top-level MIME Content Type mime-content-transfer-encoding [9] IMPLICIT AsciiPrintableString (SIZE (0..ub-mime-content-transfer-encoding)) OPTIONAL };
- トップレベルMIMEコンテンツタイプMIMEコンテンツ転送エンコード} [9] IMPLICIT AsciiPrintableString（SIZE（0..ub-MIMEコンテンツ転送エンコード））OPTIONAL。
PerRecipientFields ::= SEQUENCE
{
recipient-address EMSDORAddress,
per-recipient-flags BIT STRING
{ -- Recipient Types. -- At most one of "copy" and "blind-copy" may be -- specified concurrently for a single recipient. If -- neither is specified, than the recipient -- is assumed to be a "primary" recipient. recipient-type-copy (0), recipient-type-blind-copy (1),
{ - 受信者の種類。 - 「コピー」と「ブラインドコピー」の最も1にすることができる - 単一の受信者のために同時に指定されています。どちらも指定されていない、受信者より - - 場合は、「プライマリ」の受信者を想定しています。レシピエント型コピー（0）、受信者型ブラインドコピー（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),
- 通知要求タイプ。 - 「RN」との唯一の「NRN」に指定することができる - 同時に、\単一の受信者のためのx110011。 - "RNは" ほかに "NRN" を意味します。通知要求RN（2）、通知要求NRN（3）、通知要求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),
- レポート要求タイプ - 特定の受信者 - これらの最大1つはのために設定する必要があります。加えて - 「送達」、「配信不能」を意味します。レポート要求非配信（5）、レポート要求配信（6）、
-- Originator-to-Recipient request for a reply. reply-requested (7) } DEFAULT { report-request-non-delivery }
- 返信用オリジネータ・ツー・受信者の要求。返信要求（7）} DEFAULT {レポート要求配信不能}
};
｝；
IPMSExtension ::= SEQUENCE
{
x-header-label AsciiPrintableString,
x-header-value AsciiPrintableString
};
Body ::= SEQUENCE
{
compression-method [0] IMPLICIT CompressionMethod
OPTIONAL,
-- If compression method is not specified,
-- "no-compression" is implied.
message-body OCTET STRING -- See MIME for structure of the Body. -- If a compression method is specified, the entire text containing -- the Content-Type: element followed by the RFC-822 body are -- compressed using the specified method, and placed herein. };
メッセージボディのオクテットSTRING - ボディの構造のためのMIMEを参照してください。圧縮方式が指定されている場合、テキスト全体を含む - - のContent-Type：RFC-822本体に続く要素は、 - 指定されたメソッドを使用して圧縮され、そして本明細書中に置きました。 }。
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)
- 64と127の間番号圧縮方法であってもよい - ピア間左右合意に基づいて使用されます。 }（0..127）
END -- end of EMSD-InterpersonalMessaging1995
END - EMSD-InterpersonalMessaging1995の終わり
C RATIONALE FOR KEY DESIGN DECISIONS
KEY DESIGN決定のためのC根拠
This section summarizes the rationale behind key design decisions that were made while developing the EMSD Protocols.
このセクションでは、EMSDプロトコルを開発しながら行われた主要な設計上の決定の背後にある理論的根拠をまとめたもの。
C.1 Deviation From The SMTP Model
SMTPモデルからC.1偏差
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は、インターネットを通じて、メインのメール転送メカニズムです。 SMTPは広く普及し、よくインターネット電子メールに特化多くの技術者によって理解されています。これらの理由から、SMTPに基づいてまたはそれから派生した作品は、広くインターネット全体に展開されているの高いlikelyhoodを持っています。
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.
完全PIPELININGに最適化された場合でも、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.
EMSDのデザインを駆動する重要な要件は、効率です。これは、効率の少なくとも3倍のゲインはSMTPモデルからの偏差を正当化することを決定しました。
C.1.1 Comparison of SMTP and EMSD Efficiency
SMTPとEMSD効率のC.1.1比較
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を使用するときに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 client: message
server: accept
client: QUIT
server: ok close
client: close
C.2 Use of ESRO Instead of TCP
代わりに、TCPのESROのC.2使用
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の使用は、3つの段階があります。
Reliable transfer of a short message using TCP at a minimum involves 5 transmissions as it is the case with QMTP.
最低でTCPを使用して、ショートメッセージの信頼性の高い転送は、それがQMTPと同様に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.
EMSDのデザインを駆動する重要な要件は、効率性です。これは、TCPの固有の特徴である、余分な2つの送信の除去は、それからの逸脱を正当化することを決定しました。
ESRO protocol, as specified in (RFC-2188 [1]), provides reliable connectionless remote operation services on top of UDP [6] with minimum overhead. ESRO protocol supports segmentation and reassembly, concatenation and separation.
で指定されESROプロトコル（RFC-2188 [1]）は、最小限のオーバーヘッドで[6] UDPの上に信頼性の高いコネクションレス遠隔操作サービスを提供します。 ESROプロトコルは、セグメント化および再組み立て、連結と分離をサポートしています。
Reliable transfer of a short message using ESRO involves 3 transmissions as it is the case with EMSD-P.
それはEMSD-Pと同様にESROを用いてショートメッセージの信頼性の高い転送が3送信することを含みます。
C.3 Use Of Remote Procedure Call (RPC) Model
リモートプロシージャコール（RPC）、モデルのC.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.
EMSDにそのメッセージの送信及び配信が2つ以下のデータ交換を伴う考慮していない、テキストベースのモデルは、動作と同じになります。さらに、RPCモデルはESROを使用しての自然な方法です。
C.4 Use Of ASN.1
ASN.1のC.4使用
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は、符号化規則から抽象構文を分離するユニークな機能を持っています。 EMSDの情報オブジェクトを表現するために使用される表記法としてASN.1を選択することにより、EMSDは、それらが利用可能である圧縮符号化規則（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 FURTHER DEVELOPMENT
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.
EMSD-FSへのRFC-822のOマッピングは、より明確にする必要があります。
o Mapping of EMSD-FS to RFC-822 needs to be more explicit.
EMSD-FSのOマッピングは、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プロトコルはまた、EMSD-FSに加えて生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/.
EMSD議定書の今後の開発は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]バナン、M.、チェン、J.とM.テイラー、 "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]ブラドナーの、S.、 "要件レベルを示すRFCsにおける使用のためのキーワード"、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]クロッカー、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.
[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]ポステル、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.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。