[要約] RFC 2524は、Nedaの効率的なメール送信と配信（EMSD）プロトコル仕様バージョン1.3に関する要約と目的を提供します。このプロトコルは、効率的なメールの送信と配信を実現するための仕様を定義しています。
Network Working Group M. Banan
Request for Comments: 2524 Neda Communications, Inc.
Category: Informational February 1999
Neda's Efficient Mail Submission and Delivery (EMSD) Protocol Specification Version 1.3
NEDAの効率的なメール提出および配信（EMSD）プロトコル仕様バージョン1.3
Status of this Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（c）The Internet Society（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は、パブリックインターネット全体でエンドツーエンドの使用に完全に不適切になります。EMSDは、ワイヤレスネットワークとパブリックインターネット間で交換されたすべてのEMSD電子メールが2つの地域間のEMSD <-> SMTPゲートウェイを通過する場合にのみ、ワイヤレスネットワークで使用することを検討する必要があります。
- Inadequate security
- 不十分なセキュリティ
The document specifies only clear-text passwords for authentication. EMSD should be used across a wireless network only if sufficiently strong encryption is in use to protect the clear-text password.
ドキュメントは、認証用のクリアテキストパスワードのみを指定します。EMSDは、クリアテキストパスワードを保護するために十分に強力な暗号化が使用されている場合にのみ、ワイヤレスネットワーク全体で使用する必要があります。
- Lack of character set internationalization
- キャラクターセットの国際化の欠如
EMSD has no provision for representation of characters outside of the ASCII repertoire or for language tags.
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は、EMSDの展開を狭い状況に制限することを推奨しています。つまり、メッセージの長さと形式に固有の制限があるデバイス（ASCIIテキストの数百バイト以下）とのみ通信することを推奨しています。
a. wireless links with adequate link-layer encryption and gatewayed to the public Internet, or
a. 適切なリンク層暗号化とパブリックインターネットにゲートウェイされたワイヤレスリンク、または
b. a private IP network that is either very over-provisioned or has some means of congestion control.
b. 非常に過剰に生成されているか、輻輳制御の手段があるプライベートIPネットワーク。
In the near future, the IESG may charter a working group to define an Internet standards-track protocol for efficient transmission of electronic mail messages, which will be highly compatible with existing Internet mail protocols, and which wil be suitable for operation over the global Internet, including both wireless and wired links.
近い将来、IESGはワーキンググループをチャーターして、既存のインターネットメールプロトコルと非常に互換性があり、グローバルなインターネット上の動作に適した電子メールメッセージを効率的に送信するためのインターネット標準トラックプロトコルを定義することができます。、ワイヤレスリンクと有線リンクの両方を含む。
ABSTRACT
概要
This document specifies the protocol and format encodings for Efficient Mail Submission and Delivery (EMSD). EMSD is a messaging protocol that is highly optimized for submission and delivery of short Internet mail messages. EMSD is designed to be a companion to existing Internet mail protocols.
このドキュメントは、効率的なメールの提出と配信（EMSD）のためのプロトコルとフォーマットのエンコーディングを指定します。EMSDは、短いインターネットメールメッセージの提出と配信のために高度に最適化されたメッセージングプロトコルです。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でのメッセージ送信とメッセージ配信の信頼性要件は、既存の電子メールプロトコルと同じです。EMSDプロトコルは、RFC-2188で指定されているように、効率的な短いリモート操作（ESRO）プロトコルに加えて、信頼性の高いコネクションレスメールの提出および配信サービスを達成します[1]。
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の伝統を2つの主要な要件として、シンプルさと継続性で設計されています。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インターネットメールの提出と配信。 。 。 。 4 1.2 EMSDの他のメールプロトコルとの関係。 。 。 5 1.3 EMSD要件と目標。 。 。 。 。 。 。 7 1.4 EMSDの予想される使用。 。 。 。 。 。 。 。 8 1.5この仕様で使用される用語の定義。 。 9この仕様で使用されている1.6規則。 。 。 。 9 1.7この仕様について。 。 。 。 。 。 。 。 10 2効率的なメールの提出と配信の概要10 3効率的なメールの提出および配送プロトコル11 3.1下層の使用。 。 。 。 。 。 。 。 。 13 3.1.1 ESROSの使用。 。 。 。 。 。 。 。 。 13 3.1.2 UDPの使用。 。 。 。 。 。 。 。 。 。 13 3.1.3エンコードルール。 。 。 。 。 。 。 。 。 13 3.1.4プレゼンテーションコンテキスト。 。 。 。 。 。 。 14 3.2 EMSD-UAが操作を呼び起こしました。 。 。 。 。 。 。 14 3.2.1送信。 。 。 。 。 。 。 。 。 。 。 14 3.2.2 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セキュリティエレメント。 。 。 。 。 。 。 。 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重複操作検出サポート40
4.1 Duplicate Operation Detection Support Overview . . 40 4.1.1 Operation Value . . . . . . . . 40 4.1.2 Operation Instance Identifier . . . . . 41 5 EMSD PROCEDURE FOR OPERATIONS 42 5.1 MTS Behavior . . . . . . . . . . . 43 5.1.1 MTS Performer . . . . . . . . . 43 5.1.2 Message-submission . . . . . . . . 44 5.1.3 Delivery-control . . . . . . . . 46 5.1.4 Delivery-verify . . . . . . . . 46 5.1.5 MTS Invoker . . . . . . . . . 46 5.2 UA Behavior . . . . . . . . . . . 49 5.2.1 UA Performer . . . . . . . . . 49 5.2.2 UA Invoker . . . . . . . . . . 52 6 EMSD FORMAT STANDARDS 54 6.1 Format Standard Overview . . . . . . . . 54 6.2 Interpersonal Messages . . . . . . . . 54 6.2.1 Heading fields . . . . . . . . . 55 6.2.2 Body part types . . . . . . . . 61 7 ACKNOWLEDGMENTS 62 8 SECURITY CONSIDERATIONS 62 9 AUTHOR'S ADDRESS 62 A EMSD-P ASN.1 MODULE 63 B EMSD-IPM ASN.1 MODULE 74 C RATIONALE FOR KEY DESIGN DECISIONS 78 C.1 Deviation From The SMTP Model . . . . . . 78 C.1.1 Comparison of SMTP and EMSD Efficiency . . . 78 C.2 Use of ESRO Instead of TCP . . . . . . . 79 C.3 Use Of Remote Procedure Call (RPC) Model . . . . 79 C.4 Use Of ASN.1 . . . . . . . . . . . 80 D FURTHER DEVELOPMENT 81 E REFERENCES 82 F FULL COPYRIGHT STATEMENT 83
4.1重複操作検出サポートの概要。 。 40 4.1.1操作値。 。 。 。 。 。 。 。 40 4.1.2操作インスタンス識別子。 。 。 。 。 41 5操作のためのEMSD手順42 5.1 MTS動作。 。 。 。 。 。 。 。 。 。 。 43 5.1.1 MTSパフォーマー。 。 。 。 。 。 。 。 。 43 5.1.2メッセージサブミット。 。 。 。 。 。 。 。 44 5.1.3配信制御。 。 。 。 。 。 。 。 46 5.1.4配信-Verify。 。 。 。 。 。 。 。 46 5.1.5 MTS Invoker。 。 。 。 。 。 。 。 。 46 5.2 UA動作。 。 。 。 。 。 。 。 。 。 。 49 5.2.1 UAパフォーマー。 。 。 。 。 。 。 。 。 49 5.2.2 UA Invoker。 。 。 。 。 。 。 。 。 。 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モジュール63 B EMSD-IPM ASN.1モジュール74 C主要な設計決定の理論的根拠78 C.1 SMTPモデルからの逸脱。 。 。 。 。 。 78 C.1.1 SMTPとEMSD効率の比較。 。 。 78 c.2 TCPの代わりにESROの使用。 。 。 。 。 。 。 79 C.3リモートプロシージャコール（RPC）モデルの使用。 。 。 。 79 C.4 ASN.1の使用。 。 。 。 。 。 。 。 。 。 。 80 Dさらなる開発81 E参照82 Fフル著作権声明83
1 PRELIMINARIES
1つの予選
Mail in the Internet was not a well-planned enterprise, but instead arose in more of an "organic" way.
インターネットでのメールはよく計画された企業ではありませんでしたが、代わりに「オーガニック」の方法で発生しました。
This introductory section is not intended to be a reference model and concept vocabulary for mail in the Internet. Instead, it only provides the necessary preliminaries for the concepts and terms that are essential to this specification.
この紹介セクションは、インターネット内のメールの参照モデルおよび概念語彙であることを意図したものではありません。代わりに、この仕様に不可欠な概念と用語に必要な予備を提供するだけです。
For the purposes of this specification, mail submission is the process of putting mail into the mail transfer system (MTS).
この仕様の目的のために、メールの提出は、メール転送システム（MTS）にメールを入力するプロセスです。
For the purposes of this specification, mail delivery is the process of the MTS putting mail into a user's final mail-box.
この仕様の目的のために、メール配信は、MTSがユーザーの最終メールボックスにメールを入れるプロセスです。
Throughout the Internet, presently most of mail submission and delivery is done through SMTP.
インターネット全体で、現在、メールの提出と配達のほとんどはSMTPを介して行われています。
SMTP was defined as a message *transfer* protocol, that is, a means to route (if needed) and deliver mail by putting finished (complete) messages in a mail-box. Originally, users connected to servers from terminals, and all processing occurred on the server. Now, a split-MUA (Mail User Agent) model is common, with MUA functionality occurring on both the user's own system and the server.
SMTPは、メッセージ * Transfer *プロトコル、つまりルーティング（必要に応じて）を配信してメールボックスにメールを配信する手段として定義されていました。もともと、ユーザーは端子からサーバーに接続され、すべての処理がサーバーで発生しました。現在、Split-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.
Split-MUAモデルでは、ユーザーにメッセージを届けることは、POPやIMAPなどのプロトコルを介してサーバー上のメールボックスへのアクセスを通じて達成されます。Split-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.
Split-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倍の効率です。EMSDとSMTP、POP、およびIMAPを比較するさまざまな効率研究が利用可能です。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. 既存の主流のインターネットメールの拡張として機能します。
4. Minimize the number of transmissions.
4. トランスミッションの数を最小限に抑えます。
5. Minimize the number of bytes transmitted.
5. 送信されるバイト数を最小限に抑えます。
6. Be quick: minimize latency of message submission and delivery.
6. 迅速に：メッセージの送信と配信の遅延を最小限に抑えます。
7. Provide the same level of reliability (or higher) that the existing email protocols provide.
7. 既存の電子メールプロトコルが提供するのと同じレベルの信頼性（またはそれ以上）を提供します。
8. Accommodate varying sizes of messages: the size of a message may determine how the system deals with the message, but the system must accommodate it.
8. さまざまなサイズのメッセージに対応する：メッセージのサイズは、システムがメッセージをどのように扱うかを決定する場合がありますが、システムはそれに対応する必要があります。
9. Be power efficient and respect mobile platform resources: including memory and CPU levels, as well as battery power longevity (i.e. client-light and server-heavy).
9. 電力効率が高く、モバイルプラットフォームのリソースを尊重します。メモリとCPUレベル、バッテリー電源の寿命（つまり、クライアントライトとサーバーが多い）を含みます。
10. Highly extendible: different users will demand different options, so the solution cannot require every feature to be a part of every message. Likewise, usage will emerge that is not currently recognized as a requirement. The solution must be extendible enough to handle new, emerging requirements.
10. 非常に拡張可能：ユーザーが異なる場合は異なるオプションを要求するため、ソリューションはすべての機能をすべてのメッセージの一部にすることを要求することはできません。同様に、現在は要件として認識されていない使用法が出現します。ソリューションは、新しい新しい要件を処理するのに十分拡張可能でなければなりません。
11. Secure: provide the same level of security (or higher) that the existing email protocols provide. Content confidentiality, originator/recipient authentication and message integrity must be available options to users.
11. 安全：既存の電子メールプロトコルが提供する同じレベルのセキュリティ（またはそれ以上）を提供します。コンテンツの機密性、発信者/受信者認証、メッセージの整合性は、ユーザーが利用できるオプションでなければなりません。
12. Easy to implement: Re-use existing technology as much as possible.
12. 実装が簡単：既存のテクノロジーを可能な限り再利用します。
Any network and network operator which has significant bandwidth and capacity limitations can benefit from the use of EMSD. Any network user who must bear high costs for measured network usage can benefit from the use of EMSD.
大幅な帯域幅と容量の制限を持つネットワークおよびネットワークオペレーターは、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;
o ほとんどのワイヤレスネットワークは、IPベースであることに向けて収束するものでなければなりません。
o that two-way paging is the main proven application in most wide-area wireless networks;
o その双方向のページングは、ほとんどの広い地域のワイヤレスネットワークで主な実績のあるアプリケーションです。
o that two-way paging industry and the Internet Email industry can and should converge based on a set of open protocols that address the efficiency requirements adequately;
o 双方向のページング業界とインターネットメール業界は、効率の要件に適切に対処する一連のオープンプロトコルに基づいて収束することができます。
o that existing Internet email protocols are not bandwidth efficient;
o 既存のインターネットメールプロトコルが帯域幅効率的ではないこと。
o that existing Internet email protocols do not properly support the "push" model of delivery of urgent messages,
o 既存のインターネットメールプロトコルが、緊急メッセージの配信の「プッシュ」モデルを適切にサポートしていないこと、
the EMSD protocol is designed to facilitate the convergence of IP-based two-way paging and Internet email.
EMSDプロトコルは、IPベースの双方向ページングおよびインターネットメールの収束を促進するように設計されています。
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.
Efficive Mail Submission Server Agent（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.
Efficive Mail Submissionユーザーエージェント（EMS-UA）：このプロトコル仕様に準拠し、EMS-SAにメールを送信する申請プロセス。
Efficient Mail Delivery User Agent (EMD-UA): An Application Process which conforms to this protocol specification and accepts delivery of mail from EMD-SA. Efficient Mail Submission and Delivery User Agent (EMSD-UA): An Application Process which incorporates both EMS-UA and EMD-UA capabilities.
効率的なメール配信ユーザーエージェント（EMD-UA）：このプロトコル仕様に準拠し、EMD-SAからのメールの配信を受け入れるアプリケーションプロセス。効率的なメール提出および配信ユーザーエージェント（EMSD-UA）：EMS-UAとEMD-UA機能の両方を組み込んだアプリケーションプロセス。
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this specification are to be interpreted as defined in [2].
この仕様の「必須」、「必要はない」、「そうでなければならない」、「すべきではない」、「そうでない」、「必要はない」は、[2]で定義されていると解釈されます。
This specification uses the ES-OPERATION notation defined in Efficient Short Remote Operations (ESRO) protocols as specified in RFC-2188 [1].
この仕様では、RFC-2188で指定されているように、効率的な短いリモート操作（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-OperationおよびASN.1表記を使用して説明されます。
The complete machine verifiable ASN.1 modules are also compiled in one place in Appendix A and Appendix B.
完全なマシン検証可能なASN.1モジュールは、付録Aと付録Bの1つの場所にもコンパイルされています。
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-サーバーエージェント（メッセージセンターなど）とEMSD-ユーザーエージェント（双方向のページャーなど）間でメッセージを転送するために使用されます。図2を参照してください。
This specification defines the protocols between an EMSD - User Agent (EMSD-UA) and an EMSD - Server Agent (EMSD-SA). The EMSD - P&FS consist of two independent components:
この仕様は、EMSD-ユーザーエージェント（EMSD -UA）とEMSD -サーバーエージェント（EMSD -SA）の間のプロトコルを定義します。EMSD -P＆FSは、2つの独立したコンポーネントで構成されています。
1. EMSD Format Standard (EMSD-FS).
1. EMSDフォーマット標準（EMSD-FS）。
EMSD-FS is a non-textual form of compact encoding of Internet mail (RFC-822) messages which facilitates efficient transfer of messages. EMSD-FS is used in conjunction with the EMSD-P but is
EMSD-FSは、メッセージの効率的な転送を容易にするインターネットメール（RFC-822）メッセージのコンパクトなエンコードの非テキスト形式です。EMSD-FSはEMSD-Pと組み合わせて使用されますが、
not a general replacement for RFC-822. EMSD-FS defines a method of representation of short interpersonal messages. It defines the "Content" encoding (Header + Body). Although EMSD-FS contains end-to-end information its scope is purely point-to-point. EMSD-FS relies on EMSD-P (see 2 below) for the transfer of the content to its recipients.
RFC-822の一般的な代替品ではありません。EMSD-FSは、短い対人メッセージの表現方法を定義します。「コンテンツ」エンコード（ヘッダーボディ）を定義します。EMSD-FSにはエンドツーエンドの情報が含まれていますが、その範囲は純粋にポイントツーポイントです。EMSD-FSは、コンテンツを受信者に転送するためにEMSD-P（以下2を参照）に依存しています。
This is described in the section entitled EMSD Format Standards.
これは、EMSD形式標準というタイトルのセクションで説明されています。
2. Efficient Mail Submission and Delivery Protocol (EMSD-P).
2. 効率的なメールの提出および配信プロトコル（EMSD-P）。
EMSD-P is responsible for wrapping an EMSD-FS message (see 1 above) in a point-to-point envelope and submitting or delivering it. EMSD-P relies on the services of Efficient Short Remote Operation Services (ESROS) as specified in RFC-2188 [1] for transporting the point-to-point envelope. Some of the services of EMSD-P include: message originator authentication and optional message segmentation and reassembly. The EMSD-P is expressed in terms of abstract services using the ESROS notation. This is described in the section entitled Efficient Mail Submission and Delivery Protocol.
EMSD-Pは、ポイントツーポイントエンベロープでEMSD-FSメッセージ（上記1を参照）をラップし、それを送信または配信する責任があります。EMSD-Pは、ポイントツーポイントエンベロープを輸送するためのRFC-2188 [1]で指定されているように、効率的な短いリモート操作サービス（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がエンドツーエンドではなく、メッセージのポイントツーポイント転送に焦点を当てることを認識することが重要です。2つのポイントはEMSD-SAとEMSD-UAです。EMSD-Pは、インターネットメール環境の要素として機能します。インターネットメール環境は、エンドツーエンド（他のメッセージングオリジネーターまたは受信者にEMSDユーザー）サービスを提供します。
Figure 2 illustrates how the EMSD-P&FS defines the communication between a specific EMSD-UA and a specific EMSD-SA. The Message Transfer System may include a number of EMSD-SAs. Each EMSD-SA may have any number of EMSD-UAs with which it communicates.
図2は、EMSD-P＆FSが特定のEMSD-UAと特定のEMSD-SAの間の通信をどのように定義するかを示しています。メッセージ転送システムには、多くのEMSD-SASが含まれる場合があります。各EMSD-SAには、通信するEMSD-UAの任意の数があります。
The Efficient Mail Submission and Delivery Services use the Efficient Short Remote Operation Services (ESROS). They also use the Duplicate Operation Detection Support Functions as described in the section entitled Duplicate Operation Detection Support Functions. These functions guarantee that an operation is performed no more than once.
効率的なメールの提出および配送サービスは、効率的な短いリモート操作サービス（ESRO）を使用しています。また、Duplicate操作検出サポート機能というタイトルのセクションで説明されているように、重複操作検出サポート機能も使用します。これらの関数は、操作が1回しか実行されないことを保証します。
3 EFFICIENT MAIL SUBMISSION AND DELIVERY PROTOCOL
3効率的なメールの提出および配信プロトコル
EM Submission is the process of transferring a message from EMSD-UA to EMSD-SA. EM Delivery is the process of transferring a message from EMSD-SA to EMSD-UA.
EM提出は、EMSD-UAからEMSD-SAにメッセージを転送するプロセスです。EM配信は、EMSD-SAからEMSD-UAにメッセージを転送するプロセスです。
The Message-submission service enables an EMSD-UA to submit a message to the EMSD-SA for transfer and delivery to one or more recipients. The Message-submission Service comprises of the submit operation -- invoked by the EMSD-UA -- and possibly the submitVerify operation -- invoked by the EMSD-SA.
メッセージサブミットサービスにより、EMSD-UAは、1人以上の受信者への転送および配信のためにEMSD-SAにメッセージを送信できます。Message-Submission Serviceは、EMSD-UAによって呼び出された送信操作で構成され、場合によってはEMSD-SAによって呼び出されました。
The Message-delivery service enables the EMSD-SA to deliver a message to an EMSD-UA. The Message-delivery Service comprises of the deliver operation -- invoked by the EMSD-SA -- and possibly the deliverVerify operation -- invoked by the EMSD-UA.
メッセージ配信サービスにより、EMSD-SAはEMSD-UAにメッセージを配信できます。メッセージ配信サービスは、EMSD-UAによって呼び出された配信操作（EMSD-SAによって呼び出された操作）と、おそらく配信操作で構成されています。
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 配信制御（配信制御操作）。
EMSD-SA uses the following services:
EMSD-SAは次のサービスを使用します。
o Message-delivery
o メッセージ配信
o Submission-control (the submissionControl operation).
o 提出制御（SubmissionControl操作）。
This specification expresses information objects using ASN.1 [X.208].
この仕様では、asn.1 [x.208]を使用して情報オブジェクトを表します。
This specification expresses Remote Operations based on the model of ESROS as specified in Efficient Short Remote Operations (RFC-2188) [1]. The ES-OPERATION notation of (RFC-2188) is used throughout this specification to define specific operations.
この仕様では、効率的な短いリモート操作（RFC-2188）で指定されている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.
（RFC-2188 [1]）で指定されているESROプロトコルは、UDP [6]に最小のオーバーヘッドで信頼性の高いコネクションレスリモート操作サービスを提供します。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).
EMSD-PからESROは、UDP [6]ポート番号642（ESRO-EMSDP）を使用する必要があります。
Note that specification of Service Access Points (SAP) for EMSD-P include the UDP Port Number specification in addition to ESRO SAP selector specifications. In other words, EMSD-P's use of ESRO SAPs does not preclude use of the same SAP selectors by other protocols which use a UDP port other than port 642. Such usage of ESRO is a design characteristic of ESRO which results into bandwidth efficiency and is not a scalability limitation.
EMSD-Pのサービスアクセスポイント（SAP）の仕様には、ESRO SAPセレクターの仕様に加えて、UDPポート番号の仕様が含まれていることに注意してください。言い換えれば、EMSD-PのESRO SAPの使用は、ポート642以外のUDPポートを使用する他のプロトコルによる同じSAPセレクターの使用を排除するものではありません。ESROのこのような使用は、帯域幅効率をもたらすESROの設計特性であり、スケーラビリティの制限ではありません。
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.オクテット文字列とビット文字列値、および「原始」または「構築」としてエンコードされる可能性のあるその他のネイティブASN.1タイプは、常に「原始」としてエンコードされ、決して「構築」されてはなりません。
Parameter Encoding Type of "0" MUST be used in ESRO Protocol to identify Basic Encoding Rules for operation arguments.
操作引数の基本的なエンコードルールを識別するために、ESROプロトコルで「0」のタイプのパラメーターエンコードタイプを使用する必要があります。
The following operations are invoked by EMSD-UA:
次の操作は、EMSD-UAによって呼び出されます。
a. submit
a. 参加する
b. deliveryControl
b. DeliveryControl
c. deliveryVerify
c. DeliveryVerify
The submit operation uses the duplication detection functional unit while deliveryControl and deliveryVerify don't use the duplication detection.
送信操作では、重複検出機能ユニットを使用しますが、DearviranceControlと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の送信により、EMSD-UAは1人以上の受信者への転送および配信のためにEMSD-SAにメッセージを送信できます。
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-Operationの正常に完了したことは、EMSD-SAがメッセージに対する責任を受け入れたことを意味します（ただし、意図した受信者に配信したということではありません）。
The disruption of the ES-OPERATION by an error signifies that the EMSD-SA cannot assume responsibility for the message.
エラーによるES操作の混乱は、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,
- 効率的な輸送セグメントINFOセグメントインフォインフォーオプションのセグメンテーション機能、
-- Content type of the message content-type ContentType,
- コンテンツタイプメッセージコンテンツタイプのコンテンツタイプ、
-- -- THE CONTENT -- --
- - コンテンツ - -
-- The submission content content ANY DEFINED BY content-type };
- コンテンツタイプで定義された提出コンテンツコンテンツ};
The fields are:
フィールドは次のとおりです。
Security
安全
See Section 3.4.1, "SecurityElements".
セクション3.4.1「セキュリティエレメント」を参照してください。
Segment-info
セグメント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
Message-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-IDENTIFIERが含まれています。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.
配信制御により、EMSD-UAはEMSD-SAが呼び出す可能性のある操作と、EMSD-SAがメッセージ配信ES-Operationを介して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-Operationが正常に完了すると、指定されたコントロールが現在有効であることを意味します。
The ES-OPERATION returns an indication of any ES-OPERATIONS that the EMSD-SA would invoke, or any message types that the EMSD-SA would deliver, were it not for the prevailing controls.
ES-Operationは、EMSD-SAが呼び出すES操作、またはEMSD-SAが提供するメッセージタイプの兆候を返します。
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]暗黙の制限デフォルトの更新、
-- Which operations are to be placed in the restriction set permissible-operations [1] IMPLICIT Operations OPTIONAL,
- どの操作が制限セットに配置されるか許容操作[1]オプション、暗黙の操作、
-- What maximum content length should be allowed permissible-max-content-length
- 最大コンテンツの長さは許容可能な最大値を許可する必要があります
[2] IMPLICIT INTEGER (0..ub-content-length) OPTIONAL,
[2] 暗黙の整数（0..ub-Content-Length）オプション、
-- What is the lowest priority message which may be delivered permissible-lowest-priority
- 許容可能な低優先度を提供できる最優先メッセージは何ですか
[3] IMPLICIT ENUMERATED { non-urgent (0), normal (1), urgent (2) } OPTIONAL,
[3] 暗黙の列挙{非緊急（0）、正常（1）、緊急（2）}オプション、
-- Security features security [4] IMPLICIT SecurityElement OPTIONAL,
- セキュリティ機能セキュリティ[4]暗黙のセキュリティエレメントオプション、
-- User Feature selection user-features [5] IMPLICIT OCTET STRING OPTIONAL };
- ユーザー機能選択ユーザーフィーチュア[5]暗黙のオクテット文字列オプション};
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操作のコントロールを更新または削除するかどうかを示します。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-operationsの配信を呼び出すことはできません。と
o Other ES-OPERATIONS are not subject to controls, and may be invoked at any time.
o 他のES運動はコントロールの対象ではなく、いつでも呼び出される場合があります。
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
許容可能な最大長
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がEMSD-UAに配信ES操作を介して配信する最優先の優先順位が含まれています。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.
この引数には、提出操作の優先順位の引数の次の値の1つがある場合があります：正常、非緊急、または緊急です。
In the absence of this argument, the priority of the lowest priority message that the EMSD-SA shall deliver to the EMSD-UA is unchanged.
この議論がない場合、EMSD-SAがEMSD-UAに配信するという最優先メッセージの優先度は変更されていません。
Security
安全
See Section 3.4.1, "SecurityElements".
セクション3.4.1「セキュリティエレメント」を参照してください。
User-features
ユーザーフィーチャー
This argument contains information that allows the EMSD-UA to convey to MTS the feature set that the user is capable of supporting. This argument will be defined when the setConfiguration and getConfiguration operations are defined.
この引数には、EMSD-UAがユーザーがサポートできる機能セットをMTSに伝えることができる情報が含まれています。この引数は、setConfigurationおよびgetConfiguration操作が定義されているときに定義されます。
Results
結果
DeliveryControlResult ::= SEQUENCE
{
-- Operation types queued at the EMSD-SA due to existing
-- restrictions.
waiting-operations [0] IMPLICIT Operations DEFAULT { },
-- Types of messages queued at the EMSD-SA due to
-- existing restrictions
waiting-messages [1] IMPLICIT WaitingMessages
DEFAULT { },
-- Content Types of messages queued at the EMSD-SA waiting-content-types SEQUENCE SIZE (0..ub-content-types) OF ContentType DEFAULT { }
-ContentType default {}のEMSD-SA待機コンテンツタイプのシーケンスサイズ（0..ub-Content-Types）でキューに掲載されたコンテンツの種類のタイプ
};
};
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-operationsの配信を呼び出します。
In the absence of this result, it may be assumed that the EMSD-SA is not holding any messages for delivery due to the prevailing controls.
この結果がない場合、EMSD-SAは、一般的なコントロールのために配信用のメッセージを保持していないと想定される場合があります。
Waiting-messages
待っているメッセージ
This result indicates the kind of messages the EMSD-SA is holding for delivery to the EMSD-UA, and would deliver via the deliver ES-OPERATIONS, if it were not for the prevailing controls. It may be generated by the EMSD-SA.
この結果は、EMSD-SAがEMSD-UAへの配信のために保持しているメッセージの種類を示しており、一般的なコントロールがない場合は、ES操作の配信を介して配信されます。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.
derveryverify es-operationsにより、EMSD-UAは、eS-operationsの故障を受信したときにメッセージの配信を検証できます。
deliveryVerify ES-OPERATION
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
};
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-IDENTIFIERが含まれています。それは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-sent-out
This result indicates that EMSD-SA has received the delivery verify
この結果は、EMSD-SAが配信検証を受け取ったことを示しています
and has sent the delivery report out.
配達レポートを送信しました。
Non-Delivery-report-is-sent-out
非配達のレポート-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-Operationsの配信により、EMSD-SAはEMSD-UAにメッセージを配信できます。
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.
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メッセージデリバリタイムデータタイムによって受信者に配信された時間、
-- Time EMSD-SA originally took responsibility for processing
-- of this message. This field shall be omitted if the message-id
-- contains an EMSDLocalMessageId, because that field contains
-- the submission time within it.
message-submission-time [0] IMPLICIT DateTime OPTIONAL,
-- Security features security [1] IMPLICIT SecurityElement OPTIONAL,
- セキュリティ機能セキュリティ[1]暗黙のセキュリティエレメントオプション、
-- SegContentTypementation features for efficient transport segment-info SegmentInfo OPTIONAL,
-segContentTypementation効率的な輸送セグメントINFOセグメントインフォインフォーオプションのための機能
-- The type of the content content-type 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-IDENTIFIERが含まれています。EMSD内では、EMSD-SAによって生成される必要があり、メッセージが送信されたときにメッセージの発信元に供給されたメッセージサブリミッツ-Identifierと同じ値を持たなければなりません。
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-operationsにより、EMSD-SAはEMSD-UAが呼び出す可能性のある操作を一時的に制限することができ、EMSD-UAが送信ES-Operationsを介してEMSD-SAに提出する可能性のあるメッセージが可能になります。
The duplicate operation detection is not required for this operation.
この操作には、重複操作検出は必要ありません。
The EMSD-UA should hold until a later time, rather than abandon, ES-OPERATIONS and messages that are presently suspended.
EMSD-UAは、現在吊り下げられているES操作とメッセージを放棄するのではなく、後の時間まで保持する必要があります。
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が提出制御を再投与するまで有効であり続けます。
The ES-OPERATIONS returns an indication of any ES-OPERATIONS that the EMSD-UA would invoke were it not for the prevailing controls.
ES-operationsは、EMSD-UAが一般的なコントロールのためではない場合、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]オプション、暗黙の操作、
-- What maximum content length should be allowed permissible-max-content-length [2] IMPLICIT INTEGER (0..ub-content-length) OPTIONAL,
- 最大コンテンツの長さを許可する必要があるものを許可する必要があります[2]暗黙的整数（0..ub-Content-Length）オプション、
-- Security features security [3] IMPLICIT SecurityElement OPTIONAL };
- セキュリティ機能セキュリティ[3]暗黙のセキュリティエレメントオプション};
Restrict
制限
This argument indicates whether the controls on ES-OPERATIONS are to be updated or removed. It may be generated by the EMSD-SA.
この引数は、ES操作のコントロールを更新または削除するかどうかを示します。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は、送信局を呼び出すことができない可能性があります。と
o Other ES-OPERATIONS are not subject to controls, and may be invoked at any time.
o 他のES運動はコントロールの対象ではなく、いつでも呼び出される場合があります。
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
許容可能な最大長
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-operationsを介してEMSD-SAに提出するという最も長いコンテンツメッセージのコンテンツレングス（オクテット）が含まれています。EMSD-SAによって生成される場合があります。
In the absence of this argument, the permissible-maximum-content-length of a message that the EMSD-UA may submit to the EMSD-SA is unchanged.
この議論がない場合、EMSD-UAがEMSD-SAに提出する可能性のあるメッセージの許容可能な最大含有長の長さは変更されていません。
Security
安全
See Section 3.4.1, "SecurityElements".
セクション3.4.1「セキュリティエレメント」を参照してください。
Results
結果
SubmissionControlResult ::= SEQUENCE
{
-- Operation types queued at the EMSD-SA due to existing
-- restrictions.
waiting-operations [0] IMPLICIT Operations DEFAULT { }
};
};
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-Operationsを呼び出します。
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-Operationsにより、EMSD-SAはEMSD-UAがその提出の結果を受け取ったかどうかを確認できます。
submissionVerify ES-OPERATION
supmissionverify 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
};
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-IDENTIFIERが含まれています。それはEMSD-SAによって生成され、メッセージが送信されたときにメッセージの発信者に提供されたメッセージサブミッション識別子と同じ値を持つものとします。
Results
結果
SubmissionVerifyResult ::= SEQUENCE
{
status SubmissionStatus
};
SubmissionStatus::= ENUMERATED { send-message (1), drop-message (2) };
submissionStatus :: = Enumerated {send-message（1）、drop-message（2）};
Send-message
メッセージを送る
This result indicates that EMSD-SA is supposed to send the message out.
この結果は、EMSD-SAがメッセージを送信することになっていることを示しています。
Drop-message
ドロップメッセージ
This result indicates that EMSD-SA is supposed to drop the message.
この結果は、EMSD-SAがメッセージをドロップすることになっていることを示しています。
Errors
エラー
See Section 3.4.3.
セクション3.4.3を参照してください。
SecurityElement ::= SEQUENCE
{ credentials Credentials, contentIntegrityCheck ContentIntegrityCheck OPTIONAL };
{資格情報、ContentIntegrityCheck ContentIntegrityCheckオプション};
Credentials ::= CHOICE
{
simple [0] IMPLICIT SimpleCredentials
-- Strong Credentials are for future study
-- strong [1] IMPLICIT StrongCredentials
-- externalProcedure [2] EXTERNAL
};
SimpleCredentials ::= SEQUENCE
{
eMSDAddress EMSDAddress OPTIONAL,
password [0] IMPLICIT OCTET STRING
SIZE (0..ub-password-length)) OPTIONAL
};
-- StrongCredentials ::= NULL
-- for now.
-- ContentIntegrityCheck is a 16-bit checksum of content
ContentIntegrityCheck ::= INTEGER (0..65535);
Small messages can benefit from the efficiencies of connectionless feature of ESROS (See Efficient Short Remote Operations, RFC-2188 [1]).
小さなメッセージは、ESROSのコネクションレス機能の効率性から恩恵を受けることができます（効率的な短いリモート操作、RFC-2188 [1]を参照）。
Very large messages are transferred using protocols (e.g., SMTP) that rely on Connection Oriented Transport Service (e.g., TCP).
非常に大きなメッセージは、接続指向輸送サービス（TCPなど）に依存するプロトコル（例：SMTP）を使用して転送されます。
When a message is too large to fit in a single connectionless PDU but is not large enough to justify the overhead of connection establishment, it may be more efficient for the message to be segmented and reassembled while the connectionless service of ESROS is used. If the underlying Remote Operation Service is capable of efficient segmentation/reassembly over connectionless (CL) services,
メッセージが大きすぎて単一のコネクションレスPDUに収まるが、接続確立のオーバーヘッドを正当化するほど大きくない場合、ESROSのコネクションレスサービスを使用している間、メッセージをセグメント化および再組み立てする方が効率的かもしれません。基礎となるリモート操作サービスが、ConnectionLess（CL）サービスよりも効率的なセグメンテーション/再組み立てが可能な場合、
then use of the segmenting/reassembly mechanism introduced in this section is not necessary. This feature is accommodated in this layer by:
次に、このセクションで導入されたセグメント化/再組み立てメカニズムの使用は必要ありません。この機能は、次のようなレイヤーに収容されています。
SegmentInfo ::= CHOICE
{ first [APPLICATION 2] IMPLICIT FirstSegment, other [APPLICATION 3] IMPLICIT OtherSegment };
{first [アプリケーション2]暗黙のファーストセグメント、その他[アプリケーション3]暗黙のその他のセグメント};
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.
セグメンテーションと再組み立ては、メッセージsubmissionとメッセージ配信にのみ適用されます。
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に適合するセグメントにセグメント化する責任があります。セグメント化されたコンテンツは、それぞれコンテンツのセグメントを運ぶ一連のメッセージセグメントで送信されます。Sequence-IDは、すべてのメッセージセグメントに存在する一意の識別子です。シーケンス識別子に加えて、最初のメッセージセグメントは、セグメントの総数（セグメント数）を指定します。他のメッセージセグメントには、セグメントシーケンス番号（セグメント番号）があります。レシーバーは、メッセージ全体を再組み立てする（セグメント番号に基づく）シーケンスを担当します。
Segmenting over the Connectionless ESRO Service
Connectionless ESROサービスのセグメント化
The sender of the message maps the original message into an ordered sequence of message-segments. This sequence shall not be interrupted by other messages over the same ESROS association.
メッセージの送信者は、元のメッセージをメッセージセグメントの順序付けられたシーケンスにマッピングします。このシーケンスは、同じESROS協会の他のメッセージによって中断されてはなりません。
All message-segments in the sequence shall be assigned a sequence identifier by sender. The sequence identifier shall be incremented by one by the sender after transmission of a complete message sequence.
シーケンス内のすべてのメッセージセグメントには、送信者によってシーケンス識別子が割り当てられます。シーケンス識別子は、完全なメッセージシーケンスを送信した後、送信者によって1つずつ増加するものとします。
The first message-segment specifies the total number of segments. All message-segments in the sequence except the first one shall be sequentially numbered, starting at 1 (first message-segment has implicit segment number of 0).
最初のメッセージセグメントは、セグメントの総数を指定します。最初のメッセージを除くシーケンス内のすべてのメッセージセグメントは、1から始まる順次番号を付けなければなりません（最初のメッセージセグメントには暗黙のセグメント番号0）。
Each message-segment is transmitted by issuing a Message-submission or Message-delivery ES-OPERATIONS. All segments of a segmented message are identified by the same sequence-id. For a given message, the receiver should not impose any restriction on the order of arrival of message-segments.
各メッセージセグメントは、メッセージsubmissionまたはメッセージ配信のes-operationsを発行することにより送信されます。セグメント化されたメッセージのすべてのセグメントは、同じシーケンスIDによって識別されます。特定のメッセージの場合、受信者はメッセージセグメントの到着順序に制限を課すべきではありません。
There is no requirement that any message-segment content be of maximum length allowed by ESROS for connectionless transmission; however, no more than ub-total-number-of-segments segments can be derived from a single message.
メッセージセグメントコンテンツは、ESROSがConnectionlessの伝送に許可する最大長であるという要件はありません。ただし、UB-Total-Number-of-Segmentsセグメントは、単一のメッセージから導き出すことができません。
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とは対照的に）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.
前のセグメントの結果を待たずにセグメント。そのような場合、送信者側にメッセージセグメントの成功と失敗の任意の組み合わせがあるかもしれません。
Receiver uses the error code ResourceError (see Section 3.4.3) to ask for retransmission of a single segment and uses the error code MessageError (see Section 3.4.3) to ask for retransmission of all segments (the whole message).
受信者は、エラーコードResourceError（セクション3.4.3を参照）を使用して、単一のセグメントの再送信を要求し、エラーコードメッセージエラー（セクション3.4.3を参照）を使用して、すべてのセグメント（メッセージ全体）の再送信を要求します。
Reassembly Timer
再組み立てタイマー
The Reassembly Timer is a local timer maintained by the receiver of message-segments that assists in performing the reassembly function. This timer determines how long a receiver waits for all segments of a message-segment sequence to be received. The timer protects the receiver from the loss of a series of segments and possible sequence identifier wrap-around.
再組み立てタイマーは、再組み立て関数の実行を支援するメッセージセグメントの受信者によって維持されるローカルタイマーです。このタイマーは、受信者がメッセージセグメントシーケンスのすべてのセグメントが受信されるのを待つ時間を決定します。タイマーは、一連のセグメントの損失と可能なシーケンス識別子ラップアラウンドから受信機を保護します。
The Reassembly Timer shall be started on receipt of a message-segment with different sequence identifier than that previously received. The timer shall be stopped on receipt of all segments composing the sequence.
再組み立てタイマーは、以前に受信したものとは異なるシーケンス識別子を持つメッセージセグメントの受領時に開始するものとします。タイマーは、シーケンスを構成するすべてのセグメントの受領時に停止するものとします。
The value of Reassembly Timer is defined based on the network characteristics and the number of segments. This requires that the transmission of all segments of a single message must be completed within this time limit.
再組み立てタイマーの値は、ネットワーク特性とセグメントの数に基づいて定義されます。これには、単一のメッセージのすべてのセグメントの送信がこの時間制限内に完了する必要があります。
protocolVersionNotRecognized ERROR PARAMETER NULL ::= 1;
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
messageidentifierinvalid
The Message Identifier Invalid error reports that the Message Identifier presented to the MTS is not considered valid.
メッセージ識別子無効なエラーは、MTSに提示されたメッセージ識別子が有効とは見なされないことを報告しています。
securityError
セキュリティエラー
The Security error reports that the requested operation could not be provided by the MTS or MTS-user because it would violate the security policy in force.
セキュリティエラーは、要求された操作は、有効なセキュリティポリシーに違反するため、MTSまたはMTSユーザーが提供できなかったと報告しています。
deliveryControlViolated
配信がコントロール溶解しました
The Delivery control violated error reports the violation by the MTS of a control on delivery operations imposed by the MTS-user via the Delivery-control operation.
配信制御違反はエラーを報告しています。MTS-Userが配信制御操作を介して課せられた配信操作に関する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
プロトコル化
Indicates that one or more mandatory argument(s) were missing.
1つ以上の必須の引数が欠落していることを示します。
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
-- Content types beyond and including 64 are for
-- bilaterally-agreed use between peers.
} (0..127);
If this message was originated as an RFC-822 message, then this EMSDMessageId shall be the "Message-Id:" field from that message. If this message was originated within the EMSD domain, then this identifier shall be unique for the EMSD-SA generating this id.
このメッセージがRFC-822メッセージとして発信された場合、このEMSDMESSAGEIDは、そのメッセージからの「メッセージID：」フィールドになります。このメッセージがEMSDドメイン内で発信された場合、この識別子は、このIDを生成するEMSD-SAにとって一意でなければなりません。
EMSDMessageId ::= CHOICE
{
EMSDLocalMessageId [APPLICATION 4]
IMPLICIT EMSDLocalMessageId,
rfc822MessageId [APPLICATION 5] IMPLICIT AsciiPrintableString
rfc822messageid [アプリケーション5]暗黙のasciiprintablestring
(SIZE (0..ub-message-id-length)) };
（size（0..ub-message-id-length））};
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-name [0]暗黙のオクテット文字列（サイズ（0..ub-emsd-name-length））optional};
Originator and Recipients in the scope of EMSD network are identified by a digit based addressing scheme. EMSDAddress can only be used where the scope of addressing has clearly been limited to the EMSD network.
EMSDネットワークの範囲内のオリジネーターと受信者は、桁ベースのアドレス指定スキームによって識別されます。EmsDaddressは、アドレス指定の範囲が明らかにEMSDネットワークに限定されている場合にのみ使用できます。
DateTime ::= INTEGER;
DateTime is a Julian date, expressed as the number of seconds since 00:00:00 UTC, January 1, 1970.
DateTimeはジュリアンの日付であり、1970年1月1日、00:00:00 UTC以来秒数として表されます。
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 }
version-minor [0]暗黙の整数デフォルト0}
Table 1 provides a comprehensive summary of EMSD-P operations, the SAP selectors used and the operation IDs used.
表1は、EMSD-P操作、使用されたSAPセレクター、および使用される操作IDの包括的な要約を示しています。
Submission
提出
The semantics of a submission operation is Exactly Once. Exactly Once means that every operation is carried out exactly one time, no more and no less. This semantic can not be fully implemented because, if after invoking the operation, an invoker has a Success (e.g. result) indication and the performer has a FAILURE.indication, and the network goes down, the result of the operation will be Zero (and not Exactly Once).
提出操作のセマンティクスは一度だけです。一度には、すべての操作が正確に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).
重複した操作検出サポート機能を使用して、パフォーマーによって制御および保証されているものは1つだけです（Duplicate操作検出サポートというタイトルの章を参照）。
Not zero but one is realized by performer by using the SubmissionVerify operation. When the performer receives FAILURE.indication, it's responsibility is to resolve the case by using SubmissionVerify resulting in Not zero but one.
ゼロではありませんが、submissionverify操作を使用することにより、パフォーマーによって実現されます。パフォーマーが失敗を受け取るとき、indicationは、submissionverifyを使用してゼロではなく1つになることにより、ケースを解決することです。
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.
o EMSD-SAのパフォーマーが障害を受け取った場合、submissionverifyを呼び出します。
o Message is sent out by EMSD-SA only if result operation is confirmed or the operation is verified (in the case of FAILURE.indication).
o 結果操作が確認されているか、操作が検証された場合にのみ、メッセージがEMSD-SAによって送信されます（故障の場合）。
The semantic of SubmissionVerify operation is At Least Once. This type of semantics corresponds to the case that invoker keeps trying over and over until it gets a proper reply. This operation can be performed more than once without any harm.
SubmissionVerify操作のセマンティックは少なくとも1回です。このタイプのセマンティクスは、適切な返信が得られるまで、招待者が何度も何度も試し続ける場合に対応しています。この操作は、害を及ぼすことなく複数回実行できます。
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回実行されることを意味します。このセマンティックは完全に実装できません。操作を呼び出した後、招待者が成功し、パフォーマーが失敗し、ネットワークがダウンし、操作の結果はゼロになります（正確ではありません）。
No more than one is controlled and guaranteed by performer and by using the Duplicate Operation Detection Support Functions.
パフォーマーによって制御および保証され、重複操作検出サポート機能を使用して制御および保証されます。
Not zero but one is realized by performer by using the DeliveryVerify operation. When performer receives FAILURE.indication, it's responsible to resolve the case by using DeliveryVerify resulting in Not zero but one.
ゼロではありませんが、derviralverify操作を使用することにより、パフォーマーによって実現されます。パフォーマーが失敗を受け取ると、dearventiveverifyを使用してゼロではなく1つになることでケースを解決する責任があります。
Delivery procedure is as follows:
配信手順は次のとおりです。
o Deliver operation with 3-Way handshake is invoked.
o 3ウェイハンドシェイクで操作を配信します。
o If performer at User Agent (device) receives FAILURE.indication, it invokes DeliveryVerify.
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操作のセマンティックは少なくとも1回です。このタイプのセマンティクスは、適切な返信が得られるまで、招待者が何度も何度も試し続ける場合に対応しています。この操作は、害を及ぼすことなく複数回実行できます。
Implications:
意味：
o A non-delivery report is sent by MTS only if the message is not delivered.
o メッセージが配信されない場合にのみ、MTSによって送信されていないレポートが送信されます。
o The UA is responsible for notifying the MTS (through an explicit deliveryVerify) to make sure that a delivery report is sent out.
o UAは、MTSに通知（明示的な配信verifyを介して）を通知して、配信レポートが送信されることを確認する責任があります。
4 DUPLICATE OPERATION DETECTION SUPPORT
4重複操作検出サポート
Some operations are idempotent in nature, i.e. they can be performed more than once without any harm. However, some other operations are non-idempotent in nature, i.e. they should be performed only once. In the case of non-idempotent operations, performer should be able to detect duplicate operations and perform each non-idempotent operation only once.
一部の操作は本質的に等隊です。つまり、害を及ぼすことなく複数回実行できます。ただし、他のいくつかの操作は本質的に非人能能力です。つまり、それらは一度だけ実行する必要があります。非公開操作の場合、パフォーマーは重複操作を検出し、各非公開操作を1回だけ実行できる必要があります。
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サービスは、操作の重複の呼び出しを検出しません。その結果、同じ操作インスタンスが複数回呼び出された場合、重複した操作検出サポート機能ユニットを使用して重複を検出します。Invokerは操作インスタンス識別子を操作に割り当て、この操作インスタンス識別子をピアパフォーマーエンティティで使用して、同じ操作の重複呼び出しを検出します。
Using this support, non-idempotent operations can be repeated over and over with no harm because the duplicate invocations are detected by this functional unit. This support helps the performer not to perform an operation more than once.
このサポートを使用して、非公開操作は、この機能ユニットによって重複する呼び出しが検出されるため、害を伴わずに繰り返し繰り返すことができます。このサポートは、パフォーマーが操作を複数回実行しないのに役立ちます。
Support for duplication detection is realized through allocating Operation Instance Id (see Section 4.1.2, "Operation Instance Identifier") to an operation by invoker. When an operation is invoked using duplication detection support, performer logs the Operation Instance Identifier and checks the next operations against duplication.
重複検出のサポートは、操作インスタンスID（セクション4.1.2、「操作インスタンス識別子」を参照）をINVOKERによる操作に割り当てることにより実現されます。複製検出サポートを使用して操作が呼び出されると、パフォーマーは操作インスタンス識別子を記録し、次の操作を複製に対してチェックします。
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.
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つのグループに分けられます。0から31の動作値には、操作検出サポートが重複していません（0〜31）、32から63の動作値には、操作検出サポートが重複しています。
Duplicate Operation Detection Functional Unit checks for duplication only if Operation Value is in the range of 32 to 63.
重複操作検出機能ユニットは、操作値が32〜63の範囲である場合にのみ、重複をチェックします。
When invoker user uses an Operation Value in the range of 32 to 63 which means operation with support for duplication detection, the user should specify an Operation Instance ID for the operation (see next section).
Invokerユーザーが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:
重複検出をサポートするために、操作インスタンス識別子がInvokerユーザーによって割り当てられ、操作のパラメーターの最初のバイトとして送信されます。この識別子は、同じ操作の重複呼び出しを検出するために、パフォーマー側で使用されます。操作インスタンス識別子の特性は次のとおりです。
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ビットですが、パフォーマンスの機能に応じて、重複検出のために0〜127の操作インスタンス識別子を維持する可能性があります。パフォーマープロファイルは、重複に対してチェックされている未解決の操作インスタンス識別子の数を定義します。パフォーマープロファイルが0の未解決操作インスタンス識別子のサポートを示している場合、それは重複操作検出のサポートがないことを意味します。この場合、どの時点でも1つの未解決の操作しかないはずです。
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 Invokerユーザーは、Invokeサービスを要求した時点で、Operation Instance Identifierを操作に割り当てます。操作値は、重複検出サポート、つまり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 操作を操作を明確に識別する方法でOperation Instance Identifierを選択するのは、ユーザーの責任です。
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 操作インスタンス識別子uniqは、非公開操作を指定し、そのような操作の複数の呼び出しは最終的に同じ結果になります。
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回、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 パフォーマー側では、操作インスタンス識別子を受信すると、この最新の操作識別子が操作インスタンス識別子番号のラップアラウンド範囲の半分以上が有効期限が切れます。-bit操作インスタンス識別子、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 Invokerユーザーが連続した操作インスタンス識別子番号を使用するか、または操作インスタンス識別子をスキップする場合、上記の距離でパフォーマー側に小さい操作インスタンス識別子がある場合、有効期限が切れることを覚えておく必要があります。
5 EMSD PROCEDURE FOR OPERATIONS
5操作のための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.
次のセクションでは、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 DEREVIRYVERIFYの表示;
o Result and Error indication for a submissionVerify operation;
o submissionverify操作の結果とエラーの表示。
o Result and Error indication for a submissionControl operation;
o 提出コントロール操作の結果とエラーの表示。
o DeliveryControl indication.
o DERVILYCERCONTROLの表示。
For an ESROS event responsibility is passed to the MTS performer (Section 5.1.1).
ESROSイベントの場合、責任はMTSパフォーマーに渡されます（セクション5.1.1）。
If the MTS received an event:
MTSがイベントを受け取った場合：
o for message delivery, from the RFC-822 mailer;
o RFC-822メーラーからのメッセージ配信。
o requesting submission controls upon the UA, or;
o UAに提出コントロールを要求する、または;
o indicating an elapsed timer (meaning that it's time to re-attempt a message delivery)
o 経過タイマーを示す（メッセージ配信を再試行する時が来たことを意味します）
then responsibility is passed to the MTS invoker (Section 5.1.5).
その後、責任はMTS招待者に渡されます（セクション5.1.5）。
The MTS performer is responsible for processing the following operations, received from ESROS:
MTSパフォーマーは、ESROSから受け取った次の操作の処理を担当しています。
o Message-submission
o メッセージサブミット
o Delivery-control
o 配信制御
o Delivery-verify
o 配信-Verify
The MTS performer should first make sure that it has received an INVOKE.indication. Any other type of primitive shouldn't be occurring at this point, and should be ignored.
MTSパフォーマーは、最初にInvoke.indicationを受け取ったことを確認する必要があります。この時点で他のタイプの原始が発生しないでください。無視する必要があります。
If there's something wrong with the PDU or operation data, the MTS performer should send back an error to the proper invoker:
PDUまたは操作データに何か問題がある場合、MTSパフォーマーは適切な招待者にエラーを送信する必要があります。
1. Send an ESROS Error Request, then go wait for a response (either a confirmation or a failure indication). The response is sent back on the same SAP type on which the event occurred.
1. ESROSエラーリクエストを送信してから、応答（確認または障害表示のいずれか）を待ちます。応答は、イベントが発生したのと同じSAPタイプで送信されます。
2. Keep track of the type of request that was issued.
2. 発行されたリクエストの種類を追跡してください。
If there isn't anything wrong with the PDU or operation data, then the MTS performer has received a valid event from ESROS. This could be any of the defined Submission and Delivery Protocol operations.
PDUまたは操作データに問題がない場合、MTSパフォーマーはESROSから有効なイベントを受け取りました。これは、定義された提出および配信プロトコル操作のいずれかである可能性があります。
1. The Message-submission operation first checks to see which SAP this Submit Request came in on.
1. メッセージサブミット操作は、最初にチェックして、この送信リクエストがどのSAPリクエストが入ったかを確認します。
2. The request could have arrived as 2-Way SAP (see #3) or a 3-Way SAP (see #7).
2. リクエストは、2ウェイSAP（＃3を参照）または3ウェイSAP（＃7を参照）として到着した可能性があります。
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を参照）またはfails.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.
6. ErrorRequestの結果が障害である場合、UAが何も受け取っていない（error.request PDUが失われた）と想定できます。これは、UAの障害を意味します。または、3ウェイの承認が失われたことです。つまり、UAは実際にエラーを受け取ったことを意味します。いずれにせよ、メッセージは無視できます。これ以上のことは何もないので、返してください。
7. If the event was received on the 3-Way SAP, then this is the correct SAP on which to receive a Submit Request. Send back a Result Request and keep track of the primitive which was issued.
7. イベントが3ウェイSAPで受信された場合、これは送信リクエストを受信する正しいSAPです。結果リクエストを送信し、発行されたプリミティブを追跡します。
8. Now wait for a response to our request. The response will be either a Result.confirm (see #9) or a Failure.indication (see #13).
8. 今、私たちの要求への応答を待ちます。応答は、result.confirm（＃9を参照）またはfails.indication（＃13を参照）のいずれかです。
9. The RESULT.request has been confirmed.
9. 結果が確認されました。
10. Submit the message to the RFC-822 mailer.
10. RFC-822メーラーにメッセージを送信します。
11. Attempt, a number of times, to send the submitted message via the RFC-822 mailer. If the send was successful, then return.
11. 何度も、RFC-822メーラーを介して送信されたメッセージを送信しようとします。送信が成功した場合は、戻ります。
12. If, after the maximum number of retries, the message was not able to be sent, consider it a failure. Since the UA assumption has been that submission was successful, but now it has not been sent, a brand new message, a Non-Delivery message, must be generated and delivered to the UA. When this is completed, then return.
12. 再試行の最大数の後、メッセージを送信できなかった場合、失敗と考えてください。UAの仮定は、提出が成功したが、今では送信されていないため、新しいメッセージ、非配信メッセージを生成してUAに配信する必要があります。これが完了したら、戻ります。
13. A FAILURE.indication has occurred due to the previously issued RESULT.request.
13. 以前に発行された結果のために、障害が発生しました。
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. result.requestが受信されたかどうかを確認するために、UAに提出検証が発行されます。提出検証をUAに送信することから3つの結果があります：fail（＃15を参照）、メッセージの送信（＃16を参照）、またはドロップメッセージ（＃20を参照）。
15. Fail -- The Submission-verify request didn't reach the UA, or the Submission Verify response didn't get back. Ignore the message and return.
15. 失敗-Submission-VerifyリクエストはUAに到達しなかったか、提出された検証応答が戻ってこなかった。メッセージを無視して戻ります。
16. The Submission Verify operation succeeded, meaning that the UA received the request, and responded with a message stating that it wants the message to be sent.
16. 提出された検証操作は成功しました。つまり、UAがリクエストを受け取ったことを意味し、メッセージの送信を望んでいることを示すメッセージで応答しました。
17. Attempt, a number of times, to send the submitted message via the RFC-822 mailer.
17. 何度も、RFC-822メーラーを介して送信されたメッセージを送信しようとします。
18. If the message was submitted to the RFC-822 mailer successfully, then return. If, after the maximum number of retries, the message was not able to send the message, consider it a failure.
18. メッセージがRFC-822メーラーに正常に送信された場合は、返されます。再試行の最大数の後、メッセージがメッセージを送信できなかった場合、失敗と考えてください。
19. The UA already assumes that the Message-submission was successful. Now since the submitted message has not been sent, a brand new message, a Non-Delivery message, must be generated and delivered to the UA. After this is accomplished, then return.
19. UAは、メッセージの補給が成功したとすでに想定しています。提出されたメッセージが送信されていないため、新しいメッセージ、非配信メッセージを生成してUAに配信する必要があります。これが達成された後、戻ってきます。
20. The UA responded with a message stating that the message should be dropped. This may occur if the UA never received the result from the MTS, meaning that it never received the Message Id, and had to therefore inform the user that the message couldn't be submitted. This may also occur if the UA doesn't have the record of the message being verified. It can be because the message record has been aged and expired, or because the EMSD-UA has not been able to keep the record of the received message because of storage or memory limitations. There is nothing to do, so return.
20. UAは、メッセージを削除する必要があることを示すメッセージで応答しました。これは、UAがMTSの結果を受け取らなかった場合に発生する可能性があります。つまり、メッセージIDを受信したことがないため、メッセージを送信できないことをユーザーに通知する必要がありました。これは、UAにメッセージが検証されているという記録がない場合にも発生する可能性があります。メッセージレコードが熟成され、期限切れになっているため、またはEMSD-UAがストレージまたはメモリの制限のために受信したメッセージの記録を維持できなかったためです。何もすることはないので、返してください。
This operation can be processed immediately. After it is processed, the appropriate result is returned.
この操作はすぐに処理できます。処理された後、適切な結果が返されます。
This operation occurs when the UA doesn't think that the MTS has received the RESULT.indication from a previously delivered message. The UA wants to make sure that the MTS knows it has been delivered. The MTS will determine what it knows of the specified message, and send back a result. This can be processed immediately, as it doesn't need to deal with duplicate detection.
この操作は、UAがMTSが以前に配信されたメッセージから結果を受信したとは思わないときに発生します。UAは、MTSがそれが配信されたことを知っていることを確認したいと考えています。MTSは、指定されたメッセージについて知っていることを決定し、結果を送り返します。これは、重複検出に対処する必要がないため、すぐに処理できます。
The MTS invoker is responsible for processing the following operations, received from ESROS:
MTS Invokerは、ESROから受け取った以下の操作の処理を担当しています。
o Message-delivery
o メッセージ配信
o Submission-control
o 提出制御
o Submission-verify
o submission-verify
Submission-control
提出制御
Process the Submission Control request.
提出制御要求を処理します。
Message-delivery
メッセージ配信
1. Check the User Agent's profile to determine the SAP.
1. SAPを決定するには、ユーザーエージェントのプロフィールを確認してください。
2. Set the SAP to 3-Way.
2. 樹液を3ウェイに設定します。
3. Issue the INVOKE.request on the appropriate SAP, with duplication detection enabled. Since a local error is possible on issuing the INVOKE.request, a retry counter is needed.
3. 適切なSAPでInvoke.Requestを発行し、重複検出を有効にします。invoke.requestを発行する際にローカルエラーが可能であるため、再試行カウンターが必要です。
4. There are three possible events possible in result to the INVOKE.request: an ERROR.indication (see #5), a RESULT.indication (see #9) or a FAILURE.indication (see #10).
4. Invoke.Request：anrer.indication（＃5を参照）、結果（＃9を参照）、または故障（＃10を参照）（＃10を参照）を得て、結果に可能なイベントが3つあります。
5. An ERROR.indication was received, which means that the UA can't accept the message right now.
5. 誤差が受信されました。つまり、UAは今すぐメッセージを受け入れることができません。
6. If the reason was one of a transient nature, wait for a while and then send the Deliver Request again.
6. 理由が一時的な性質の1つである場合は、しばらく待ってから、配信リクエストを再度送信してください。
7. If the reason was one of a permanent nature, send back a non-delivery report to the originator.
7. 理由が恒久的な性質の1つである場合、独創的な報告書を元の人に送り返してください。
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. エラーは永続的な性質の1つであるため、MTSは非配信レポートを返送し、UAからのエラーで失敗した配信を記録して返さなければなりません。
9. A RESULT.Indication was returned, which means that the Delivery was successful. Send a delivery report to the originator if one was requested and log successful delivery and return.
9. 結果が返されました。つまり、配達が成功したことを意味します。要求された場合は、発信者に配達レポートを送信し、配達を成功させて返送します。
If the UA profile indicated that Complete mode was to be used, keep track of the fact that this message has been successfully delivered (as far as the MTS is concerned), so that if the UA sends us a Delivery Verify operation, we know that we consider the message to be delivered.
UAプロファイルが完全なモードを使用することを示した場合、このメッセージが正常に配信されたという事実を追跡してください（MTSに関する限り）。メッセージが配信されると考えています。
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. 失敗が返されました。つまり、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
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.
Submission-Verify操作は、常に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を発行し、重複検出が無効になっています。Invokeリクエストの発行に関するローカルエラーが可能であるため、再試行カウンターが必要です。
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が発行され、応答が受けられました。応答は、結果.indication（＃3を参照）または障害（＃4を参照）のいずれかです。提出された検証操作に定義されたエラーはないため、ここではエラーが発生しないでください。
3. A RESULT.indication was received. Either ResponseSendMessage or ResponseDropMessage, as specified in the PDU, will be returned.
3. 結果。PDUで指定されているように、ResponseSendMessageまたはRespondedRopmessageのいずれかが返されます。
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. 障害が受け取られました。つまり、提出物を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.
Invoke.Requestは、コンテンツタイプの非配信レポートを含む送信操作を含むRequestをUAに発行します。この操作は、常に2ウェイSAPで発行されます。応答が待っています。応答が発生しない場合、リクエストは列に並び、後で再び試みられます。
1. Create a Submit operation.
1. 送信操作を作成します。
2. Issue the INVOKE.request on the 2-Way SAP, with duplication detection enabled. Since a local error on issuing the invoke request is possible, a retry counter for is needed.
2. 2ウェイSAPでInvoke.Requestを発行し、重複検出を有効にします。Invokeリクエストの発行に関するローカルエラーが可能であるため、再試行カウンターが必要です。
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への応答が受信されました。応答は、結果.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. 誤差が受信されました。つまり、UAは私たちの非配信レポートをどうするかわからないことを意味します。それがUASの問題ですので、何もして戻ってください。
5. A RESULT.indication was received, which means we delivered a successful non-delivery report.
5. 結果が受け取られました。つまり、成功した非配信レポートを提供しました。
6. The result is logged. Nothing more is needed, so return.
6. 結果が記録されます。これ以上必要ないので、返品してください。
7. A FAILURE.indication was received, which means there was a problem getting the Submit Request to the UA, or in getting the response back from the UA. In any case, the response was never, so the request timed out. Wait for a while, and then send the Submission Verify request again.
7. 障害が受け取られました。つまり、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
メッセージ配信
1. A Message-delivery request is received.
1. メッセージ配信リクエストが受信されます。
2. Check for the correctness of the PDU. If the PDU is bad the see #3. If the PDU is good then see #8.
2. PDUの正しさを確認してください。PDUが悪い場合は、＃3を参照してください。PDUが良い場合は、＃8を参照してください。
3. Send an ESROS ERROR.request. If the request arrived on a 3-Way SAP, use a 3-Way SAP for the result. If the request arrived on a 2-Way SAP, use a 2-Way SAP for the result. Keep track of the type of request that was issued.
3. ESROS ERROR.Requestを送信します。リクエストが3ウェイSAPに届いた場合は、結果に3ウェイSAPを使用します。リクエストが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を参照）またはfails.indication（＃7を参照）である可能性があります。
5. The ESROS event was an ERROR.confirm
5. ESROSイベントはerror.confirmでした
6. Log the message as the Non-Delivery was confirmed by the MTS and return.
6. 非配信がMTSによって確認されて返されるため、メッセージを記録します。
7. If the ESROS event was a FAILURE.indication, that means one of two things has occurred:
7. ESROSイベントが失敗である場合、それは2つのことのうちの1つが発生したことを意味します。
A. The MTS has received nothing (the ERROR.request PDU was lost), which means that the MTS doesn't know that the message delivery has been rejected. In this case, the MTS will eventually time out, and retransmit the message delivery request.
A. MTSは何も受け取っていません（Error.Request PDUは失われました）。つまり、MTSはメッセージ配信が拒否されたことを知らないことを意味します。この場合、MTSは最終的にタイムアウトし、メッセージ配信リクエストを再送信します。
B. The 3-Way acknowledgment was lost, which means that the MTS has in fact received the ERROR.request PDU and knows about the delivery failure.
B. 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を参照）またはfails.indication（＃13を参照）である可能性があります。
10. If the event is a RESULT.confirm, then the delivered message can now be given to the user.
10. イベントがresult.confirmである場合、配信されたメッセージをユーザーに提供できるようになりました。
11. Deliver the message to the user.
11. メッセージをユーザーに配信します。
12. Log the message as Message Delivery Known to MTS.
12. MTSに知られているメッセージ配信としてメッセージを記録します。
13. If the event is a FAILURE.indication, then, if the delivery was on a 3-Way SAP, a Delivery Verification request to the MTS can be issued to see if the MTS actually got the RSULT.request. If the delivery was on a 2-Way SAP, then the message will delivered to the user and if the MTS has not received the RESULT.request, it will retransmit it later and the duplicate will be ignored.
13. イベントが障害である場合、配信が3方向SAPにある場合、MTSが実際にRSult.Requestを取得したかどうかを確認するために、MTSへの配信確認要求を発行できます。配信が2ウェイSAPにある場合、メッセージはユーザーに配信され、MTSが結果を受信していない場合、後で再送信し、重複は無視されます。
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. メッセージをユーザーに配信します。result.requstに応じて失敗を受けることが受信されたため、MTSは結果を受け取らなかったことを意味します。MTSはタイムアウトして、同じメッセージの別のコピーを送信できます。複製検出のためにメッセージを保存します。
15. Log the fact that the message was delivered, but that the MTS might not be aware of it.
15. メッセージが配信されたが、MTSがそれを認識していないかもしれないという事実を記録します。
16. If the UA supports Delivery Verification, and the Delivery Request was sent on the 3-Way SAP, then see #17. If either of these conditions are not true, then return.
16. UAが配信の確認をサポートし、配送要求が3ウェイSAPで送信された場合は、＃17を参照してください。これらの条件のいずれかが真でない場合は、戻ります。
17. Send a Delivery-verify request to see if the MTS got the RESULT.request.
17. 配信-Verifyリクエストを送信して、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).
配信検証をMTSに送信することから3つの結果があります。失敗（＃18を参照）、ResponsenOndelivery（＃20を参照）、またはRespondeDivery（＃23を参照）。
18. Fail -- Delivery Verify request didn't reach the MTS, or the Delivery Verify response didn't get back to the UA.
18. 失敗 - 配信確認要求はMTSに到達しなかったか、配信確認応答がUAに戻らなかった。
19. Log this as delivering the message to the user, but the MTS having possibly sent a Non-Delivery report to the originator even though the UA did actually deliver the message to the user. Then return.
19. これをユーザーにメッセージを配信するように記録しますが、UAが実際にユーザーにメッセージを配信したにもかかわらず、MTSがオリジナルに配信のないレポートを送信した可能性があります。その後、返します。
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-応答の検証MTSが現在知っていることを示しています（メッセージがユーザーに配信されたが結果を受信していないことを検証する配信のため、リケストも配信もタイムリーな方法で操作を検証し、すでに送信していましたオリジネーターへの配送のない報告書を出します。
21. The MTS had not received, from the UA, in a timely manner, a RESULT.indication indicating that the message had been delivered to the user. The MTS has already sent a Non-Delivery report to
21. MTSは、UAからタイムリーに、メッセージがユーザーに配信されたことを示す結果を受け取っていませんでした。MTSはすでに配送のない報告書を送信しています
the originator. The UA must let the user know about this. Log the message as delivered to the user, but a Non-Delivery sent to the originator.
オリジネーター。UAは、ユーザーにこれについて知らせる必要があります。ユーザーに配信されたメッセージをログに記録しますが、オリジネーターに送信されない配信があります。
22. Since the UA received a response to the Verify operation, it knows that the MTS knows about this message delivery, so the UA also knows that it won't be receiving a duplicate of it. The UA can now remove this message's Message Id from the list of possible duplicates.
22. UAは検証操作への回答を受け取ったため、MTSがこのメッセージ配信について知っていることを知っているため、UAはそれの複製を受け取っていないことも知っています。UAは、考えられる複製のリストからこのメッセージのメッセージIDを削除できるようになりました。
23. ResponseDelivery -- Verify Response received from MTS.
23. Ressiondelivery -MTSから受信した応答を確認します。
24. This means that the MTS knows (either because the MTS had received the RESULT.request that was sent by the UA or because the MTS has now received the UAs Delivery-verification message, informing that the UA received the message for delivery to the user. The MTS is (or was) able to send a Delivery report to the originator if one was requested. Log it as such.
24. これは、MTSが知っていることを意味します（MTSがUAによって送信された結果を受け取ったため、またはMTSがUAS配信検証メッセージを受け取ったため、UAがユーザーへの配信のメッセージを受け取ったことを意味します。MTSは、要求された場合に発信者に配信レポートを送信することができます（またはそうでした）。そのように記録します。
25. Since the UA received a response to the Verify operation, it knows that the MTS knows about this message delivery, so the UA also knows that it won't be receiving a duplicate of it. The UA can now remove this message's Message Id from the list of possible duplicates and return.
25. UAは検証操作への回答を受け取ったため、MTSがこのメッセージ配信について知っていることを知っているため、UAはそれの複製を受け取っていないことも知っています。UAは、このメッセージのメッセージIDを、可能な複製と返品のリストから削除できるようになりました。
Submission-verify
submission-verify
Process the Submission-verify request and return.
送信-Verifyリクエストを処理し、返品します。
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 配信-Verify
Message-submission
メッセージサブミット
General procedures for UA's Message-submission mirror that of MTS's Message-delivery.
UAのメッセージサブミットの一般的な手順は、MTSのメッセージ配信の一般的な手順を反映しています。
Delivery-control
配信制御
1. Issue the INVOKE.request on the 3-Way SAP, with duplication detection enabled. Since the UA can get a local error on issuing the invoke request, a retry counter is needed.
1. 重複検出が有効になった状態で、3ウェイSAPでInvoke.Requestを発行します。UAはInvokeリクエストの発行でローカルエラーを取得できるため、再試行カウンターが必要です。
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).
Invokeリクエストの発行に局所障害が発生した場合は、しばらく待ってから再試行してください（最大回収数の限界まで）。
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を参照）、または失敗（＃7を参照）のいずれかです。
3. A ERROR.indicaiton was received, meaning that the MTS told says that it cannot accept the message.
3. Error.Indicaitonが受信されました。つまり、MTSはメッセージを受け入れることができないと言ったことを意味します。
4. Log the MTS rejection and return
4. MTSの拒否を記録し、戻ります
5. A RESULT.indication was received, which means that the Submission was successful.
5. 結果が受け取られました。つまり、提出が成功したことを意味します。
6. Log successful submission and return.
6. 成功した提出と返品を記録します。
7. a FAILURE.indication was received, meaning that there was a problem getting the Submit Request to the MTS, or in getting the response back from the MTS. In any case, the UA never received the response, so the request timed out. Wait for a while, and then send the Submit Request again.
7. 失敗が受け取られました。つまり、MTSへの送信要求を取得するか、MTSから応答を取り戻すことに問題があったことを意味します。いずれにせよ、UAは応答を受け取ったことがないため、リクエストはタイムアウトしました。しばらく待ってから、送信リクエストをもう一度送信します。
8. The UA has exceeded the maximum number of retries. Let the user know, log the failure and return.
8. UAは、Retriesの最大数を超えています。ユーザーに知らせ、失敗をログにして返します。
Delivery-verify
配信-Verify
General procedures for UA's Delivery-verify mirror that of MTS's Submission-verify.
UAの配信verifyの一般的な手順は、MTSのSubmission-Verifyのものを反映しています。
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.
（o）「オプション」、（d）「デフォルト」、（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,
-- List of recipients and flags associated with each. recipient-data SEQUENCE SIZE (1..ub-recipients) OF PerRecipientFields,
- それぞれに関連する受信者とフラグのリスト。受信フィールドのレシピエントデータシーケンスサイズ（1..ub-recipients）、
-- Flags applying to this entire message per-message-flags [1] IMPLICIT BIT STRING
- このメッセージ全体に適用されるフラグは、メッセージ1枚あたり[1]暗黙のビット文字列
{
-- Priority values
-- At most one of "non-urgent" and "urgent" may be specified
-- concurrently. If neither is specified, then a Priority
-- level of "normal" is assumed.
priority-non-urgent (0),
priority-urgent (1),
-- Importance values
- 重要性の価値
-- At most one of "low" and "high" may be specified
-- concurrently. If neither is specified, then an
-- Importance level of "normal" is assumed.
importance-low (2),
importance-high (3),
-- Indication of whether this message has been automatically forwarded auto-forwarded (4) } OPTIONAL,
- このメッセージが自動的に転送されたかどうかの兆候（4）}オプション、
-- User-specified recipient who is to receive replies to this message. reply-to [2] IMPLICIT SEQUENCE SIZE (1..ub-reply-to) OF EMSDORAddress OPTIONAL,
- このメッセージに対する返信を受け取るユーザー指定の受信者。返信[2] emsdoraddressオプションの暗黙のシーケンスサイズ（1..ub-reply-to）、
-- Identifier of a previous message, for which this message
-- is a reply
replied-to-IPM EMSDMessageId OPTIONAL,
-- Subject of the message. subject [3] IMPLICIT AsciiPrintableString (SIZE (0..ub-subject-field)) OPTIONAL,
- メッセージの主題。件名[3]暗黙のasciiprintablestring（size（0..ub-subject-field））オプション、
-- RFC-822 header fields not explicitly provided for in
-- this Heading. For messages incoming from the external
-- world (i.e. in RFC-822 format), the Message-Id: field
-- need not go here, as it is placed in the
-- Envelope's EMSDMessageId (message-id) field.
extensions [4] IMPLICIT SEQUENCE
(SIZE (0..ub-header-extensions))
OF IPMSExtension OPTIONAL,
-- MIME Version (if other than 1.0) mime-version [5] IMPLICIT AsciiPrintableString (SIZE (0..ub-mime-version-length)) OPTIONAL,
-MIMEバージョン（1.0以外の場合）MIME-version [5]暗黙のasciiprintablestring（size（0..ub-mime-version-length））オプション、
-- Top-level MIME Content Type mime-content-type [6] IMPLICIT AsciiPrintableString (SIZE (0.. ub-mime-content-type-length)) OPTIONAL,
- トップレベルのマイムコンテンツタイプMIME-CONTENT-TYPE [6]暗黙のASCIIPRINTABLESTRING（サイズ（0 .. UB-Mime-Content-Length））オプション、
-- MIME Content Id mime-content-id [7] IMPLICIT AsciiPrintableString (SIZE (0.. ub-mime-content-id-length)) OPTIONAL,
-MIMEコンテンツID MIME-CONTENT-ID [7]暗黙のASCIIPRINTABLESTRING（サイズ（0 .. UB-Mime-Content-ID-Length））オプション、
-- MIME Content Description
mime-content-description [8] IMPLICIT AsciiPrintableString
(SIZE (0..ub-mime-content-
description-length))
OPTIONAL,
-- Top-level MIME Content Type
mime-content-transfer-encoding
[9] IMPLICIT AsciiPrintableString (SIZE (0..ub-mime-content-transfer-encoding)) OPTIONAL };
[9]暗黙的なasciiprintablestring（size（0..ub-mime-content-transfer-encoding））オプション};
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),
-- 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),
通知-Request-IPM-Return（4）、
-- Report Request Types
- リクエストタイプをレポートします
-- At most one of these should be set for a
-- particular recipient. "delivery" implies "non-delivery"
-- in addition.
report-request-non-delivery (5),
report-request-delivery (6),
-- Originator-to-Recipient request for a reply. reply-requested (7) } DEFAULT { report-request-non-delivery }
- 返信に対するオリジネーターからレシピエントへのリクエスト。REPLY-REQUESTED（7）} default {Report-Request-Non-Delivery}
};
};
recipient-address
受信者 - アドレス
The Primary Recipients heading field identifies the zero or more users who are the "primary recipients" of the IPM. The primary recipients might be those users who are expected to act upon the IPM.
フィールドに見られるプライマリレシピエントは、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
通知-Request-RN
A receipt notification (rn) reports its originator's receipt, or his expected and arranged future receipt, of an IPM.
領収書通知（RN）は、IPMの発信者の領収書、または彼の予想された将来の領収書を報告します。
notification-request-nrn
通知-Request-NRN
A non-receipt notification (nrn) reports its originator's failure to receive, to accept, or his delay in receiving, an IPM.
非受信通知（NRN）は、IPMをIPMを受け取ったり、受け入れたり、受信の遅延を受け取ったり、受け入れたりの遅延を報告しています。
notification-request-ipm-return
通知-Request-IPM-Return
When this field is set, the contents of the message are returned along with the notification.
このフィールドが設定されると、メッセージの内容が通知とともに返されます。
report-request-non-delivery
Report-Request-Non-Delivery
The report request enables the MTS to acknowledge to the MTS-user one or more outcomes of a previous invocation of the message-submission or probe-submission abstract-operations.
レポートリクエストにより、MTSはMTS-ユーザーに、メッセージサブミットまたはプローブサブミットの抽象操作の以前の呼び出しの1つ以上の結果を確認できます。
A report is returned only in case of non-delivery.
レポートは、配信不能の場合にのみ返されます。
report-request-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.
メッセージsubmissionの場合、レポート配信は、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
flagsprags
Priority
優先順位
The Priority field (default is normal) identifies the priority that the authorizing users attach to the IPM. It may assume any one of the following values: urgent, normal, or non-urgent.
優先度フィールド（デフォルトは通常）は、認定ユーザーがIPMに接続する優先度を識別します。次の値のいずれかを想定する場合があります：緊急、正常、または非緊急です。
At most one of either "non-urgent" or "urgent" may be specified concurrently. If neither is specified, then a Priority level of "normal" is assumed.
最大で「非緊急」または「緊急」のいずれかが同時に指定される場合があります。どちらも指定されていない場合、「通常」の優先レベルが想定されます。
Importance
重要性
The Importance heading field (default normal) identifies the importance that the authorizing users attach to the IPM. It may assume any one of the following values: low, normal, or high.
重要な見出しフィールド（デフォルトの通常）は、認定ユーザーがIPMに付着するという重要性を特定します。低、正常、または高い値のいずれかを想定する場合があります。
At most one of either "low" or "high" may be specified concurrently. If neither is specified, then a Importance level of "normal" is assumed.
最大で「低」または「高」のいずれかのいずれかが同時に指定される場合があります。どちらも指定されていない場合、「通常」の重要性レベルが想定されます。
The values above are not defined by this specification; they are given meaning by users.
上記の値は、この仕様では定義されていません。ユーザーから意味が与えられています。
auto-forwarded
自動運転
The Auto-forwarded heading field (default is false) indicates whether the IPM is the result of auto-forwarding. It is a Boolean value.
自動運転の見出しフィールド（デフォルトはfalse）は、IPMが自動配置の結果であるかどうかを示します。ブール値です。
reply-to
に返信
User-specified recipient or recipients who are to receive replies to this message.
このメッセージに対する返信を受け取るユーザー指定の受信者または受信者。
replied-to IPM
IPMに返信
The Replied-to IPM heading field (C) identifies the IPM to which the present IPM is a reply. It comprises an IPM identifier.
返信したIPM見出しフィールド（c）は、現在のIPMが返信であるIPMを識別します。IPM識別子で構成されています。
This conditional field shall be present if, and only if, the IPM is a reply.
この条件場は、IPMが返信である場合にのみ存在するものとします。
Note - In the context of forwarding, care should be taken to distinguish between the forwarding IPM and the forwarded IPM. This field should identify whichever of these two IPMs to which the reply responds.
注 - 転送のコンテキストでは、転送IPMと転送されたIPMを区別するように注意する必要があります。このフィールドは、応答が応答するこれら2つの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拡張機能のセットで構成されており、それぞれがそのような情報項目を1つ伝えています。
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.
};
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)
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.
狭帯域PCを介したCDPDおよびPACTを介した限られたサイズメッセージング（LSM）のコンテキストでは、AT＆Tワイヤレスサービス（AWS）、EMSDプロトコルの開発に関連する資金提供作業。
8 SECURITY CONSIDERATIONS
8つのセキュリティ上の考慮事項
This protocol supports simple authentication of the originator's address by the EMSD-SA and simple authentication of EMSD-SA by EMSD-UA.
このプロトコルは、EMSD-SAによるオリジネーターのアドレスの簡単な認証とEMSD-UAによるEMSD-SAの簡単な認証をサポートしています。
Mainstream Internet mail security mechanisms can be used in conjunction with the EMSD protocol.
主流のインターネットメールセキュリティメカニズムは、EMSDプロトコルと組み合わせて使用できます。
9 AUTHOR'S ADDRESS
9著者の住所
Mohsen Banan Neda Communications, Inc. 17005 SE 31st Place Bellevue, WA 98008
Mohsen Banan Neda Communications、Inc。17005 SE 31st Place Bellevue、WA 98008
EMail: mohsen@neda.com
A EMSD-P ASN.1 MODULE
EMSD-P ASN.1モジュール
This section compiles in one place the complete ASN.1 Module for EM Submission and Delivery Protocol.
このセクションは、EM提出および配信プロトコル用の完全なASN.1モジュールを1か所にコンパイルします。
EMSD-SubmissionAndDeliveryProtocol DEFINITIONS ::=
BEGIN
始める
EXPORTS EMSDORAddress, AsciiPrintableString, ContentType, DateTime, EMSDMessageId, EMSDORAddress, ProtocolVersionNumber;
emsdoraddress、asciiprintablestring、contentType、datetime、emsdmessageid、emsdoraddress、protocolversionnumber;
-- Upper bounds
- 上限
ub-recipients INTEGER ::= 256;
-- also defined in EMSD-InterpersonalMessaging1995
ub-reply-to INTEGER ::= 256;
-- also defined in EMSD-InterpersonalMessaging1995
ub-subject-field INTEGER ::= 128;
-- also defined in EMSD-InterpersonalMessaging1995
ub-password-length INTEGER ::= 16;
ub-content-length INTEGER ::= 65535;
-- also defined in EMSD-Probe
ub-content-types INTEGER ::= 128;
ub-message-id-length INTEGER ::= 127;
ub-total-number-of-segments INTEGER ::= 32;
ub-header-extensions INTEGER ::= 64;
-- also defined in EMSD-InterpersonalMessaging1995
ub-emsd-name-length INTEGER ::= 64;
ub-emsd-address-length INTEGER ::= 20;
ub-rfc822-name-length INTEGER ::= 127;
ub-mime-version-length INTEGER ::= 8;
-- also defined in EMSD-InterpersonalMessaging1995
ub-mime-content-type-length INTEGER ::= 127;
-- also defined in EMSD-InterpersonalMessaging1995
ub-mime-content-id-length INTEGER ::= 127;
-- also defined in EMSD-InterpersonalMessaging1995
ub-mime-content-description-length INTEGER ::= 127;
-- also defined in EMSD-InterpersonalMessaging1995
ub-mime-content-transfer-encoding INTEGER ::= 127;
-- also defined in EMSD-InterpersonalMessaging1995
ub-local-message-nu INTEGER ::= 4096;
----------------------
-- 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,
- 効率的な輸送セグメントINFOセグメントインフォインフォーオプションのセグメンテーション機能、
-- Content type of the message content-type ContentType,
- コンテンツタイプメッセージコンテンツタイプのコンテンツタイプ、
-- -- THE CONTENT -- --
- - コンテンツ - -
-- The submission content content ANY DEFINED BY content-type
- コンテンツタイプで定義された提出コンテンツコンテンツ
};
};
SubmitResult ::= SEQUENCE
{
{
-- Permanent identifier for this message.
-- Also contains the message submission time.
-- See comment regarding assignment of message
-- identifiers, at the definition of EMSDLocalMessageId.
message-id EMSDLocalMessageId
};
--------------------------------
-- Delivery Control Operation --
--------------------------------
deliveryControl ES-OPERATION
配信制御
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]オプション、暗黙の操作、
-- What maximum content length should be allowed permissible-max-content-length [2] IMPLICIT INTEGER (0..ub-content-length) OPTIONAL,
- 最大コンテンツの長さを許可する必要があるものを許可する必要があります[2]暗黙的整数（0..ub-Content-Length）オプション、
-- What is the lowest priority message which may be delivered permissible-lowest-priority [3] IMPLICIT ENUMERATED { non-urgent (0), normal (1), urgent (2) } OPTIONAL,
- 許容可能な低優先度[3]暗黙の列挙{非緊急（0）、通常（1）、緊急（2）}オプション、オプション、emplicityの優先権を提供できる最優先メッセージは何ですか？
-- Security features security [4] IMPLICIT SecurityElement OPTIONAL,
- セキュリティ機能セキュリティ[4]暗黙のセキュリティエレメントオプション、
-- User Feature selection user-features [5] IMPLICIT OCTET STRING OPTIONAL };
- ユーザー機能選択ユーザーフィーチュア[5]暗黙のオクテット文字列オプション};
DeliveryControlResult ::= SEQUENCE
{
-- Operation types queued at the EMSD-SA due to existing
-- restrictions.
waiting-operations [0] IMPLICIT Operations DEFAULT { },
-- Types of messages queued at the EMSD-SA due to
-- existing restrictions
waiting-messages [1] IMPLICIT WaitingMessages DEFAULT { },
待機メッセージ[1]暗黙的な待機間出来事{}、
-- Content Types of messages queued at the EMSD-SA waiting-content-types SEQUENCE SIZE (0..ub-content-types) OF ContentType DEFAULT { } };
-ContentType default {}}のEMSD-SA待機コンテンツタイプシーケンスサイズ（0..ub-Content-Types）でキューに巻かれたコンテンツの種類のタイプ。
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
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メッセージデリバリタイムデータタイムによって受信者に配信された時間、
-- Time EMSD-SA originally took responsibility for processing
-- of this message. This field shall be omitted if the message-id
-- contains an EMSDLocalMessageId, because that field contains
-- the submission time within it.
message-submission-time [0] IMPLICIT DateTime OPTIONAL,
-- Security features security [1] IMPLICIT SecurityElement OPTIONAL,
- セキュリティ機能セキュリティ[1]暗黙のセキュリティエレメントオプション、
-- SegContentTypementation features for efficient transport segment-info SegmentInfo OPTIONAL,
-segContentTypementation効率的な輸送セグメントINFOセグメントインフォインフォーオプションのための機能
-- The type of the content content-type ContentType,
- コンテンツコンテンツタイプのコンテンツタイプのタイプ、
-- -- THE CONTENT -- --
- - コンテンツ - -
-- The submitted (and now being delivered) content content ANY DEFINED BY content-type
- コンテンツタイプで定義されているコンテンツコンテンツが送信された（そして現在配信中）コンテンツ
};
};
-- Submission Control Operation
- 提出制御操作
submissionControl ES-OPERATION
ARGUMENT SubmissionControlArgument
RESULT SubmissionControlResult
ERRORS
{
securityError,
resourceError,
protocolViolation
} ::= 4;
SubmissionControlArgument ::= SEQUENCE
{
-- Request an addition of or removal of a set of restrictions
restrict [0] IMPLICIT Restrict DEFAULT update,
-- Which operations are to be placed in the restriction set permissible-operations [1] IMPLICIT Operations OPTIONAL,
- どの操作が制限セットに配置されるか許容操作[1]オプション、暗黙の操作、
-- What maximum content length should be allowed permissible-max-content-length [2] IMPLICIT INTEGER (0..ub-content-length) OPTIONAL,
- 最大コンテンツの長さを許可する必要があるものを許可する必要があります[2]暗黙的整数（0..ub-Content-Length）オプション、
-- Security features security [3] IMPLICIT SecurityElement OPTIONAL };
- セキュリティ機能セキュリティ[3]暗黙のセキュリティエレメントオプション};
SubmissionControlResult ::= SEQUENCE
{
-- Operation types queued at the EMSD-SA due to existing
-- restrictions. waiting-operations [0] IMPLICIT Operations DEFAULT { }
- 制限。待機手術[0]暗黙の操作デフォルト{}
};
};
----------------------------------
-- Submission Verify Operation --
----------------------------------
submissionVerify ES-OPERATION
supmissionverify 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) };
submissionStatus :: = Enumerated {send-message（1）、drop-message（2）};
-- GetConfiguration Operation
-- To be fully defined later. This will possibly include,
-- but not be limited to:
-- get-local-time-zone
-- get-protocol-version
-- etc.
getConfiguration ES-OPERATION
GetConfiguration ES-Operation
ARGUMENT NULL
RESULT NULL
ERRORS
{
resourceError,
protocolViolation
} ::= 7;
-- SetConfiguration Operation
-- To be fully defined later.
setConfiguration ES-OPERATION
setConfiguration es-operation
ARGUMENT NULL
RESULT NULL
ERRORS
{
resourceError,
protocolViolation
} ::= 8;
-- Security --
- 安全 -
SecurityElement ::= SEQUENCE
{ credentials Credentials, contentIntegrityCheck ContentIntegrityCheck OPTIONAL };
{資格情報、ContentIntegrityCheck ContentIntegrityCheckオプション};
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オプション、パスワード[0]暗黙的なオクテット文字列（サイズ（0..ub-password-length））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 };
{first [アプリケーション2]暗黙のファーストセグメント、その他[アプリケーション3]暗黙のその他のセグメント};
FirstSegment ::= SEQUENCE
{ sequence-id INTEGER, number-of-segments INTEGER -- number-of-segments must not exceed ub-total-number-of-segments
{sequence-id integer、ofsegments integer-of ofsegmentsをub-total-number-of-of-sgmentsを超えてはなりません
};
};
OtherSegment ::= SEQUENCE
{ sequence-id INTEGER, segment-number INTEGER };
{sequence-id integer、segment-number integer};
-----------
-- Errors --
------------
protocolVersionNotRecognized ERROR PARAMETER NULL ::= 1;
submissionControlViolated ERROR PARAMETER NULL ::= 2;
messageIdentifierInvalid ERROR PARAMETER NULL ::= 3;
securityError ERROR PARAMETER security-problem SecurityProblem ::= 4;
deliveryControlViolated ERROR PARAMETER NULL ::= 5;
resourceError ERROR PARAMETER NULL ::= 6;
protocolViolation ERROR PARAMETER NULL ::= 7;
messageError ERROR PARAMETER NULL ::= 8;
SecurityProblem ::= INTEGER (0..127);
-- -- EXPORTED Definitions (for use by associated specifications) -- --
---エクスポートされた定義（関連する仕様で使用するため） -
ContentType ::= INTEGER
{
-- Content type 0 is reserved and shall never be transmitted.
reserved (0),
-- Content types between 1 and 31 (inclusive) are for
-- internal-use only
probe (1), -- reserved
delivery-report (2), -- reserved
-- Content types between 32 and 63 (inclusive) are for
-- message types defined within this specifications.
emsd-interpersonal-messaging-1995 (32),
voice-messaging (33) -- reserved
-- Content types beyond and including 64 are for
-- bilaterally-agreed use between peers.
} (0..127);
-- If this message was originated as an RFC-822 message, then this
-- EMSDMessageId shall be the "Message-Id:" field from that message.
-- If this message was originated within the EMSD domain,
-- then this identifier shall be unique for the Message Center
-- generating this id.
EMSDMessageId ::= CHOICE
{
emsdLocalMessageId [APPLICATION 4] IMPLICIT
EMSDLocalMessageId,
rfc822MessageId [APPLICATION 5] IMPLICIT
AsciiPrintableString
(SIZE (0..ub-message-id-length))
};
};
EMSDLocalMessageId ::= SEQUENCE
{
submissionTime DateTime,
messageNumber INTEGER (0..ub-local-message-nu)
};
-- An Originator/Recipient Address in EMSD Environment
-EMSD環境のオリジネーター/受信者アドレス
EMSDORAddress ::= CHOICE
{
-- This is the local-format address emsd-local-address-format EMSDAddress,
- これは地元の形式のアドレスEMSD-Local-Address-Format 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-name [0] IMPLICIT OCTET STRING (SIZE (0..ub-emsd-name-length)) OPTIONAL };
emsd-name [0]暗黙のオクテット文字列（サイズ（0..ub-emsd-name-length））optional};
DateTime ::= INTEGER;
Iso8859String ::= GeneralString;
AsciiPrintableString ::= [ APPLICATION 0 ]
IMPLICIT Iso8859String (FROM
(" "|"!"|"#"|"$"|"%"|"&"|"'"|"("|")"|"*"|"+"|","|"-"|"."|"/"|
"0"|"1"|"2"|"3"|"4"|"5"|"6"|"7"|"8"|"9"|":"|";"|"<"|"="|">"|
"?"|"@"|"A"|"B"|"C"|"D"|"E"|"F"|"G"|"H"|"I"|"J"|"K"|"L"|"M"|
"N"|"O"|"P"|"Q"|"R"|"S"|"T"|"U"|"V"|"W"|"X"|"Y"|"Z"|"["|"]"|
"^"|"_"|"`"|"a"|"b"|"c"|"d"|"e"|"f"|"g"|"h"|"i"|"j"|"k"|"l"|
"m"|"n"|"o"|"p"|"q"|"r"|"s"|"t"|"u"|"v"|"w"|"x"|"y"|"z"|"{"|
"|"|"}"|"~"|"\"|""""));
ProtocolVersionNumber ::= [APPLICATION 1] SEQUENCE
{
version-major INTEGER,
version-minor [0] IMPLICIT INTEGER DEFAULT 0
}
END -- end of EMSD-SubmissionAndDeliveryProtocol
B EMSD-IPM ASN.1 MODULE
B EMSD-IPM ASN.1モジュール
This section compiles in one place the complete ASN.1 Module for EMSD-IPM.
このセクションは、EMSD-IPMの完全なASN.1モジュールを1か所にコンパイルします。
EMSD-InterpersonalMessaging1995 DEFINITIONS ::=
BEGIN
始める
IMPORTS EMSDORAddress, EMSDMessageId, AsciiPrintableString FROM EMSD-SubmissionAndDeliveryProtocol;
EMSDORADDRESS、EMSDMESSAGEID、ASCIIPRINTABLESTRINGをEMSD-SubmissionAndDeliveryProtocolからインポートします。
ub-recipients INTEGER ::= 256;
ub-reply-to INTEGER ::= 256;
ub-subject-field INTEGER ::= 128;
ub-header-extensions INTEGER ::= 64;
ub-emsd-name-length INTEGER ::= 64;
ub-mime-version-length INTEGER ::= 8;
ub-mime-content-type-length INTEGER ::= 127;
ub-mime-content-id-length INTEGER ::= 127;
ub-mime-content-description-length INTEGER ::= 127;
ub-mime-content-transfer-encoding INTEGER ::= 127;
IPM ::= SEQUENCE
{ heading Heading, body Body OPTIONAL };
{見出し、ボディボディオプション};
Heading ::= SEQUENCE
{
-- Address of the sending agent (person, program, machine) of
-- this message. This field is mandatory if the sender
-- is different than the originator.
sender [0] EMSDORAddress OPTIONAL,
-- Address of the originator of the message
-- (not necessarily the sender)
originator EMSDORAddress,
-- List of recipients and flags associated with each. recipient-data SEQUENCE SIZE (1..ub-recipients) OF PerRecipientFields,
- それぞれに関連する受信者とフラグのリスト。受信フィールドのレシピエントデータシーケンスサイズ（1..ub-recipients）、
-- Flags applying to this entire message per-message-flags [1] IMPLICIT BIT STRING
- このメッセージ全体に適用されるフラグは、メッセージ1枚あたり[1]暗黙のビット文字列
{
-- Priority values
-- At most one of "non-urgent" and "urgent" may be specified
-- concurrently. If neither is specified, then a Priority
-- level of "normal" is assumed.
priority-non-urgent (0),
priority-urgent (1),
-- Importance values
-- At most one of "low" and "high" may be specified
-- concurrently. If neither is specified, then an
-- Importance level of "normal" is assumed.
importance-low (2),
importance-high (3),
-- Indication of whether this message has been automatically
-- forwarded
auto-forwarded (4)
} OPTIONAL,
-- User-specified recipient who is to receive replies to this
-- message.
reply-to [2] IMPLICIT SEQUENCE SIZE
(1..ub-reply-to)
OF EMSDORAddress OPTIONAL,
-- Identifier of a previous message, for which this message
-- is a reply
replied-to-IPM EMSDMessageId OPTIONAL,
-- Subject of the message. subject [3] IMPLICIT AsciiPrintableString (SIZE (0..ub-subject-field)) OPTIONAL,
- メッセージの主題。件名[3]暗黙のasciiprintablestring（size（0..ub-subject-field））オプション、
-- RFC-822 header fields not explicitly provided for in
-- this Heading. For messages incoming from the external
-- world (i.e. in RFC-822 format), the Message-Id: field
-- need not go here, as it is placed in the
-- Envelope's EMSDMessageId (message-id) field.
extensions [4] IMPLICIT SEQUENCE
(SIZE (0..ub-header-extensions))
OF IPMSExtension OPTIONAL,
-- MIME Version (if other than 1.0) mime-version [5] IMPLICIT AsciiPrintableString (SIZE (0..ub-mime-version-length))
- mimeバージョン（1.0以外の場合）mime-version [5]暗黙のasciiprintablestring（size（0..ub-mime-version-length））
OPTIONAL,
オプション、
-- Top-level MIME Content Type mime-content-type [6] IMPLICIT AsciiPrintableString (SIZE (0.. ub-mime-content-type-length)) OPTIONAL,
- トップレベルのマイムコンテンツタイプMIME-CONTENT-TYPE [6]暗黙のASCIIPRINTABLESTRING（サイズ（0 .. UB-Mime-Content-Length））オプション、
-- MIME Content Id mime-content-id [7] IMPLICIT AsciiPrintableString (SIZE (0.. ub-mime-content-id-length)) OPTIONAL,
-MIMEコンテンツID MIME-CONTENT-ID [7]暗黙のASCIIPRINTABLESTRING（サイズ（0 .. UB-Mime-Content-ID-Length））オプション、
-- MIME Content Description mime-content-description [8] IMPLICIT AsciiPrintableString (SIZE (0.. ub-mime-content-description-length)) OPTIONAL,
- マイムコンテンツの説明mime-content-description [8]暗黙のasciiprintablestring（size（0 .. ub-mime-content-description-length））オプション、
-- Top-level MIME Content Type mime-content-transfer-encoding [9] IMPLICIT AsciiPrintableString (SIZE (0..ub-mime-content-transfer-encoding)) OPTIONAL };
- トップレベルのMIMEコンテンツタイプMIME-CONTENT-TRANSFER-ENCODING [9]暗黙のASCIIPRINTABLESTRING（サイズ（0..UB-MIME-CONTENT-TRANSFER-ENCODING））オプション};
PerRecipientFields ::= SEQUENCE
{
recipient-address EMSDORAddress,
per-recipient-flags BIT STRING
{
-- Recipient Types.
-- At most one of "copy" and "blind-copy" may be
-- specified concurrently for a single recipient. If
-- neither is specified, than the recipient
-- is assumed to be a "primary" recipient.
recipient-type-copy (0),
recipient-type-blind-copy (1),
-- Notification Request Types.
-- Only one of "rn" and "nrn" may be specified
-- concurrently, \x110011 for a single recipient.
-- "rn" implies "nrn" in addition.
notification-request-rn (2),
notification-request-nrn (3),
notification-request-ipm-return (4),
-- Report Request Types
-- At most one of these should be set for a
-- particular recipient. "delivery" implies "non-delivery"
-- in addition.
report-request-non-delivery (5),
report-request-delivery (6),
-- Originator-to-Recipient request for a reply. reply-requested (7) } DEFAULT { report-request-non-delivery }
- 返信に対するオリジネーターからレシピエントへのリクエスト。REPLY-REQUESTED（7）} default {Report-Request-Non-Delivery}
};
};
IPMSExtension ::= SEQUENCE
{
x-header-label AsciiPrintableString,
x-header-value AsciiPrintableString
};
Body ::= SEQUENCE
{
compression-method [0] IMPLICIT CompressionMethod
OPTIONAL,
-- If compression method is not specified,
-- "no-compression" is implied.
message-body OCTET STRING
-- See MIME for structure of the Body.
-- If a compression method is specified, the entire text containing
-- the Content-Type: element followed by the RFC-822 body are
-- compressed using the specified method, and placed herein.
};
CompressionMethod ::= INTEGER
{
-- Compression Methods numbered 0 to 63 are reserved for
-- assignment within this and associated specifications.
no-compression (0),
lempel-ziv (1)
-- Compression Methods numbered between 64 and 127 may be
-- used on a bilaterally-agreed basis between peers.
} (0..127)
END -- end of EMSD-InterpersonalMessaging1995
END-EMSD-InterPersonAlmessaging1995の終わり
C RATIONALE FOR KEY DESIGN DECISIONS
重要な設計上の決定の理論的根拠
This section summarizes the rationale behind key design decisions that were made while developing the EMSD Protocols.
このセクションでは、EMSDプロトコルの開発中に行われた重要な設計上の決定の背後にある理論的根拠をまとめます。
SMTP is the main mail transport mechanism throughout the Internet. SMTP is widely deployed and well understood by many engineers who specialize in Internet email. Because of these reasons, works based on SMTP or derived from it have a higher likelyhood of being widely deployed throughout the Internet.
SMTPは、インターネット全体の主要なメールトランスポートメカニズムです。SMTPは、インターネットメールを専門とする多くのエンジニアによって広く展開され、よく理解されています。これらの理由により、SMTPに基づいている、またはそれから派生した作品は、インターネット全体に広く展開される可能性が高いです。
However, SMTP is highly inefficient for transfer of short messages. SMTP's inefficiency applies to both the number of transmissions and also to the number of bytes transmitted.
ただし、SMTPは短いメッセージの転送には非常に非効率的です。SMTPの非効率性は、伝達の数と送信されるバイト数の両方に適用されます。
Even when fully optimized with PIPELINING, SMTP is still quite inefficient.
Pipelingで完全に最適化されている場合でも、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モデルからの偏差を正当化すると判断されました。
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
クライアント：メッセージサーバー：クライアントを受け入れる：QUITサーバー：OK閉じるクライアント：閉じる
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つのフェーズが含まれます。
1. Connection Establishment
1. 接続確立
2. Data Transfer
2. データ転送
3. Disconnect
3. 切断します
Reliable transfer of a short message using TCP at a minimum involves 5 transmissions as it is the case with QMTP.
QMTPの場合と同様に、TCPを最小限に使用して短いメッセージの信頼できる転送には、5つの送信が含まれます。
The key requirement driving the design of EMSD is Efficiency. It was determined that elimination of the extra 2 transmissions that are an inherent characteristic of TCP, justifies deviation from it.
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.
（RFC-2188 [1]）で指定されているESROプロトコルは、UDP [6]に最小のオーバーヘッドで信頼性の高いコネクションレスリモート操作サービスを提供します。ESROプロトコルは、セグメンテーションと再組み立て、連結、分離をサポートします。
Reliable transfer of a short message using ESRO involves 3 transmissions as it is the case with EMSD-P.
ESROを使用した短いメッセージの信頼できる転送には、EMSD-Pの場合と同様に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を使用する自然な方法です。
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さらなる開発
Beyond this documentation of existing implementations, further development of EMSD protocol is anticipated.
既存の実装のこのドキュメントを超えて、EMSDプロトコルのさらなる開発が予想されます。
The following deficiencies and areas of improvement are identified.
以下の欠陥と改善領域が特定されています。
o Mapping of RFC-822 to EMSD-FS needs to be more explicit.
o RFC-822のEMSD-FSへのマッピングは、より明確にする必要があります。
o Mapping of EMSD-FS to RFC-822 needs to be more explicit.
o EMSD-FSのRFC-822へのマッピングは、より明確にする必要があります。
o Text of duplicate detection section needs more structure.
o 重複した検出セクションのテキストには、より多くの構造が必要です。
o SubmissionControl operation needs more informative description.
o SubmissionControl操作には、より有益な説明が必要です。
o Based on implementor's feedback the "EMSD PROCEDURE FOR OPERATIONS" section needs to be adjusted or re-done.
o 実装者のフィードバックに基づいて、「操作のためのEMSD手順」セクションを調整または再起動する必要があります。
o The EMSD protocol can be extended to also support transfer of raw RFC-822 text-based messages in addition to EMSD-FS. This would be a trade-off in favor of "ease of implementation" against "efficiency of bytes transfered".
o EMSDプロトコルは、EMSD-FSに加えてRAW 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] Banan、M.、Cheng、J。、およびM. Taylor、「AT＆T/NEDAの効率的な短いリモート操作（ESRO）プロトコル仕様バージョン1.2。」、RFC 2188、1997年9月。
[2] Bradner, S., "Key words for use in RFCs to indicate requirement levels", BCP 14, RFC 2119, March 1997.
[2] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[3] Crocker, D., "Standard for the format of ARPA internet text messages", STD 11, RFC 822, August 1982.
[3] Crocker、D。、「ARPAインターネットテキストメッセージの形式の標準」、STD 11、RFC 822、1982年8月。
[4] Information Processing --- Open Systems Interconnection --- Specification of Packed Encoding Rules for Abstract Syntax Notation One (ASN.1). International Organization for Standardization and International Electrotechnical Committee. International Standard 8825-2.
[4] 情報処理---オープンシステムの相互接続---抽象的構文表記1（asn.1）のパックされたエンコードルールの指定。国際標準化および国際電気技術委員会。国際標準8825-2。
[5] Information Processing --- Open Systems Interconnection --- Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.1). International Organization for Standardization and International Electrotechnical Committee, 1987. International Standard 8825.
[5] 情報処理---オープンシステムの相互接続---抽象的構文表記1（asn.1）の基本エンコードルールの指定。国際標準化および国際電気技術委員会、1987年。国際標準8825。
[6] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[6] Postel、J。、「ユーザーデータグラムプロトコル」、STD 6、RFC 768、1980年8月。
F. Full Copyright Statement
F.完全な著作権声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（c）The Internet Society（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.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。