[要約] RFC 3801は、VPIMv2の仕様を定義しており、電子メールでの音声プロファイルを提供します。その目的は、異なるボイスメールシステム間での音声メッセージの交換を可能にすることです。
Network Working Group G. Vaudreuil
Request for Comments: 3801 Lucent Technologies
Obsoletes: 2421 G. Parsons
Category: Standards Track Nortel Networks
June 2004
Voice Profile for Internet Mail - version 2 (VPIMv2)
インターネットメールの音声プロファイル - バージョン2（VPIMV2）
Status of this Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004).
著作権（c）The Internet Society（2004）。
Abstract
概要
This document specifies a restricted profile of the Internet multimedia messaging protocols for use between voice processing server platforms. The profile is referred to as the Voice Profile for Internet Mail (VPIM) in this document. These platforms have historically been special-purpose computers and often do not have the same facilities normally associated with a traditional Internet Email-capable computer. As a result, VPIM also specifies additional functionality, as it is needed. This profile is intended to specify the minimum common set of features to allow interworking between conforming systems.
このドキュメントは、音声処理サーバープラットフォーム間で使用するインターネットマルチメディアメッセージングプロトコルの制限されたプロファイルを指定します。このドキュメントのプロファイルは、インターネットメール（VPIM）の音声プロファイルと呼ばれます。これらのプラットフォームは、歴史的に特別な目的のコンピューターであり、通常、従来のインターネット電子メール利用可能なコンピューターに関連付けられている同じ施設を持たないことがよくあります。その結果、VPIMは必要に応じて追加の機能も指定します。このプロファイルは、適合システム間のインターワーキングを可能にするために、最小共通の機能セットを指定することを目的としています。
This document obsoletes RFC 2421 and describes version 2 of the profile with greater precision. No protocol changes were made in this revision. A list of changes from RFC 2421 are noted in Appendix F. Appendix A summarizes the protocol profiles of this version of VPIM.
このドキュメントは、RFC 2421を廃止し、プロファイルのバージョン2をより正確に説明します。この改訂にはプロトコルの変更は行われませんでした。RFC 2421からの変更のリストは、付録Fに記載されています。付録Aは、このバージョンのVPIMのプロトコルプロファイルをまとめたものです。
Table of Contents
目次
1. Introduction...................................................3
1.1. Voice Messaging System Limitations.......................3
1.2. Design Goals.............................................4
1.3. Applicability for VPIM...................................5
2. Requirements Language..........................................5
3. Protocol Restrictions..........................................6
4. Voice Message Interchange Format...............................6
4.1. VPIM Message Addressing Formats..........................7
4.2. Message Header Fields....................................9
4.3. MIME Audio Content Descriptions.........................17
4.4. Voice Message Content Types.............................19
4.5. Other MIME Contents.....................................23
4.6. Delivery Status Notification (DSN)......................25
4.7. Message Disposition Notification (MDN)..................26
4.8. Forwarded Messages......................................26
4.9. Reply Messages..........................................27
5. Message Transport Protocol....................................27
5.1. Base SMTP Protocol......................................28
5.2. SMTP Service Extensions.................................28
5.3. ESMTP - SMTP Downgrading................................30
6. Directory Address Resolution..................................30
7. Management Protocols..........................................30
7.1. Network Management......................................31
8. Conformance Requirements......................................31
9. Security Considerations.......................................32
9.1. General Directive.......................................32
9.2. Threats and Problems....................................32
9.3. Security Techniques.....................................33
10. Normative References..........................................33
11. Acknowledgments...............................................36
12. Appendix A - VPIM Requirements Summary........................37
13. Appendix B - Example Voice Messages...........................43
14. Appendix C - Example Error Voice Processing Error Codes.......49
15. Appendix D - Example Voice Processing Disposition Types.......50
16. Appendix E - IANA Registrations...............................50
16.1. Voice Content-Disposition Parameter Definition.........51
16.2. Multipart/Voice-Message MIME Media Type Definition.....51
17. Appendix F - Change History: RFC 2421 (VPIM V2) To This Doc...53
18. Authors' Addresses............................................54
19. Full Copyright Statement......................................55
MIME is the Internet multipurpose, multimedia-messaging standard. This document explicitly recognizes its capabilities and provides a mechanism for the exchange of various messaging technologies, primarily voice and facsimile.
MIMEは、インターネットの多目的、マルチメディアメッセージの標準です。このドキュメントは、その機能を明示的に認識し、主に音声とファクシミリ、さまざまなメッセージングテクノロジーを交換するためのメカニズムを提供します。
Voice messaging evolved as telephone answering service into a full send, receive, and forward messaging paradigm with unique message features, semantics and usage patterns. Voice messaging was introduced on special purpose computers that interface to a telephone switch and provide call answering and voice messaging services. Traditionally, messages sent from one voice messaging system to another were transported using analog networking protocols based on DTMF signaling and analog voice playback. As the demand for networking increases, there was a need for a standard high-quality digital protocol to connect these machines. VPIM has successfully demonstrated its usefulness as this new standard. VPIM is widely implemented and is seeing deployment in customer networks. This document clarifies ambiguities found in the earlier specification and is consistent with implementation practice. The profile is referred to as Voice Profile for Internet Mail (VPIM) in this document.
音声メッセージングは、独自のメッセージ機能、セマンティクス、および使用パターンを備えた、電話応答サービスとして完全な送信、受信、およびフォワードメッセージングパラダイムに進化しました。音声メッセージングは、電話スイッチとのインターフェースを発揮し、通話応答と音声メッセージングサービスを提供する特別な目的コンピューターに導入されました。従来、ある音声メッセージングシステムから別の音声メッセージに送信されたメッセージは、DTMFシグナル伝達とアナログ音声再生に基づいたアナログネットワークプロトコルを使用して輸送されていました。ネットワーキングの需要が増加するにつれて、これらのマシンを接続するための標準的な高品質のデジタルプロトコルが必要になりました。VPIMは、この新しい標準としての有用性を成功裏に実証しました。VPIMは広く実装されており、顧客ネットワークに展開されています。このドキュメントは、以前の仕様で見つかった曖昧さを明確にし、実装の実践と一致しています。このドキュメントのプロファイルは、インターネットメール（VPIM）の音声プロファイルと呼ばれます。
This document specifies a restricted profile of the Internet multimedia messaging protocols for use between voice processing server platforms. These platforms have historically been special-purpose computers and often do not have the same facilities normally associated with a traditional Internet Email-capable computer. As a result, VPIM also specifies additional functionality, as it is needed. This profile is intended to specify the minimum common set of features to allow interworking between conforming systems.
このドキュメントは、音声処理サーバープラットフォーム間で使用するインターネットマルチメディアメッセージングプロトコルの制限されたプロファイルを指定します。これらのプラットフォームは、歴史的に特別な目的のコンピューターであり、通常、従来のインターネット電子メール利用可能なコンピューターに関連付けられている同じ施設を持たないことがよくあります。その結果、VPIMは必要に応じて追加の機能も指定します。このプロファイルは、適合システム間のインターワーキングを可能にするために、最小共通の機能セットを指定することを目的としています。
This document obsoletes RFC 2421 and describes VPIM version 2 of with greater precision. No protocol changes were made in this revision. A list of changes from RFC 2421 are noted in Appendix F. Appendix A summarizes the protocol profiles of this version of VPIM.
このドキュメントは、RFC 2421を廃止し、より正確にVPIMバージョン2について説明します。この改訂にはプロトコルの変更は行われませんでした。RFC 2421からの変更のリストは、付録Fに記載されています。付録Aは、このバージョンのVPIMのプロトコルプロファイルをまとめたものです。
The following are typical limitations of voice messaging platforms that were considered in creating this baseline profile.
以下は、このベースラインプロファイルを作成する際に考慮された音声メッセージングプラットフォームの典型的な制限です。
1) Text messages are not normally received and often cannot be easily displayed or viewed. They can often be processed only via text-to-speech or text-to-fax features not currently present in many of these machines.
1) テキストメッセージは通常受信されておらず、多くの場合、簡単に表示または表示できません。多くの場合、これらのマシンの多くには現在存在していないテキスト間またはテキスト間機能を介してのみ処理できます。
2) Voice mail machines usually act as an integrated Message Transfer Agent, Message Store and User Agent. There is typically no relaying of messages. RFC822 header fields may have limited use in the context of the limited messaging features currently deployed.
2) ボイスメールマシンは通常、統合されたメッセージ転送エージェント、メッセージストア、ユーザーエージェントとして機能します。通常、メッセージの中継はありません。RFC822ヘッダーフィールドは、現在展開されている限られたメッセージング機能のコンテキストでの使用が制限されている可能性があります。
3) Voice mail message stores are generally not capable of preserving the full semantics of an Internet message. As such, use of a voice mail machine for gatewaying is not supported. In particular, storage of recipient lists, "Received:" lines, and "Message-ID:" may be limited.
3) 通常、ボイスメールメッセージストアは、インターネットメッセージの完全なセマンティクスを保存することはできません。そのため、ゲートウェイングにボイスメールマシンを使用することはサポートされていません。特に、受信者リストのストレージ、「受信：」ライン、および「メッセージID：」は制限される場合があります。
4) Internet-style distribution/exploder mailing lists are not typically supported. Voice mail machines often implement only local alias lists, with error-to-sender and reply-to-sender behavior. Reply-all capabilities using a Cc list are not generally available.
4) インターネットスタイルの配布/爆発者メーリングリストは、通常サポートされていません。多くの場合、ボイスメールマシンは、エラーからセンダーへの応答の動作を備えたローカルエイリアスリストのみを実装します。CCリストを使用したすべての機能は一般的に利用できません。
5) Error reports must be machine-parsable so that helpful responses can be voiced to users whose only access mechanism is a telephone.
5) エラーレポートは、アクセスメカニズムのみが電話であるユーザーに有用な応答を発表できるように、機械型である必要があります。
6) The voice mail systems generally limit address entry to 16 or fewer numeric characters, and normally do not support alphanumeric mailbox names. Alpha characters are not generally used for mailbox identification, as they cannot be easily entered from a telephone terminal.
6) ボイスメールシステムは通常、16以下の数値文字へのアドレスエントリを制限し、通常は英数字のメールボックス名をサポートしません。アルファ文字は、電話端子から簡単に入力できないため、通常、メールボックスの識別には使用されません。
It should be noted that newer systems are based natively on SMTP/MIME and do not suffer these limitations. In particular, some systems may support media other than voice and fax.
新しいシステムはSMTP/MIMEにネイティブに基づいており、これらの制限に苦しんでいないことに注意する必要があります。特に、一部のシステムでは、音声とファックス以外のメディアをサポートする場合があります。
It is a goal of this profile to make as few restrictions and additions to the existing Internet mail protocols as possible while satisfying the requirements for interoperability with current generation voice messaging systems. This goal is motivated by the desire to increase the accessibility to digital messaging by enabling the use of proven existing networking software for rapid development.
現在の世代の音声メッセージングシステムとの相互運用性の要件を満たしながら、既存のインターネットメールプロトコルに可能な限り少ない制限と追加を行うことは、このプロファイルの目標です。この目標は、迅速な発展のために実証済みの既存のネットワークソフトウェアの使用を可能にすることにより、デジタルメッセージングへのアクセスを増やしたいという願望によって動機付けられています。
This specification is intended for use on a TCP/IP network; however, it is possible to use the SMTP protocol suite over other transport protocols. The necessary protocol parameters for such use are outside the scope of this document.
この仕様は、TCP/IPネットワークでの使用を目的としています。ただし、他の輸送プロトコルでSMTPプロトコルスイートを使用することは可能です。このような使用に必要なプロトコルパラメーターは、このドキュメントの範囲外です。
This profile is intended to be robust enough to be used in an environment, such as the global Internet, with installed-base gateways that do not understand MIME. Full functionality, such as reliable error messages and binary transport, will require careful selection of gateways (e.g., via MX records) to be used as VPIM forwarding agents. Nothing in this document precludes use of general-purpose MIME email packages to read and compose VPIM messages. While no special configuration is required to receive VPIM conforming messages, some may be required to originate conforming structures.
このプロファイルは、MIMEを理解していないインストールされたベースゲートウェイを備えた、グローバルインターネットなどの環境で使用できるほど堅牢であることを目的としています。信頼性の高いエラーメッセージやバイナリトランスポートなどの完全な機能には、VPIM転送エージェントとして使用するには、ゲートウェイ（例：MXレコードを介して）を慎重に選択する必要があります。このドキュメントには、VPIMメッセージを読み取り、作成するための汎用MIME電子メールパッケージの使用を妨げるものはありません。VPIM適合メッセージを受信するために特別な構成は必要ありませんが、適合構造を発信するために必要なものもあります。
It is expected that a system administrator who can perform TCP/IP network configuration will manage a VPIM messaging system. When using facsimile or multiple voice encodings, it is suggested that the system administrator maintain a list of the capabilities of the networked mail machines to reduce the sending of undeliverable messages due to lack of feature support. Configuration, implementation and management of these directory-listing capabilities are local matters.
TCP/IPネットワーク構成を実行できるシステム管理者がVPIMメッセージングシステムを管理することが期待されています。ファクシミリまたは複数の音声エンコーディングを使用する場合、システム管理者は、ネットワーク化されたメールマシンの機能のリストを維持して、機能サポートの不足により居住不可能なメッセージの送信を減らすことが提案されています。これらのディレクトリリストに登録する機能の構成、実装、および管理は、ローカルな問題です。
VPIM is intended for the exchange of voice messages between traditional voice messaging systems and for systems that need to interoperate with such systems. VPIM is intended connect voice-messaging systems into special-purpose voice messaging networks. VPIM may also be used between message store servers and VPIM-aware clients such as web servers, TUI, and GUI clients. VPIM is not intended or optimized for downloading to, or sending from commercial email clients.
VPIMは、従来の音声メッセージングシステム間の音声メッセージの交換と、そのようなシステムと相互運用する必要があるシステムを目的としています。VPIMは、音声メッセージを特別な音声メッセージングネットワークに接続することを目的としています。VPIMは、メッセージストアサーバーとWebサーバー、TUI、GUIクライアントなどのVPIM対応クライアントの間でも使用できます。VPIMは、商用電子メールクライアントへのダウンロードや送信を意図した、または最適化していません。
Internet Voice Messaging, the subject of a separate standards initiative, is intended to enable general-purpose email clients to send and receive voice content through general-purpose message stores in an interoperable way. IVM may also be a suitable format for downloading voice messages from a VPIM server to a commercial email client. It may also be a suitable format for submission of a voice message from a general-purpose client into a VPIM system.
個別の標準イニシアチブの主題であるインターネット音声メッセージングは、汎用電子メールクライアントが汎用のメッセージストアを介して音声コンテンツを送信および受信できるようにすることを目的としています。IVMは、VPIMサーバーから商用電子メールクライアントにボイスメッセージをダウンロードするのに適した形式でもあります。また、汎用クライアントからVPIMシステムに音声メッセージを送信するための適切な形式である場合があります。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [REQ].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、[req]で説明されていると解釈される。
This protocol does not limit the number of recipients per message. Where possible, server implementations should not restrict the number of recipients in a single message. It is recognized that no implementation supports unlimited recipients, and that the number of supported recipients may be quite low.
このプロトコルは、メッセージあたりの受信者の数を制限しません。可能であれば、サーバーの実装は、単一のメッセージに受信者の数を制限してはなりません。実装は無制限の受信者をサポートしていないこと、およびサポートされている受信者の数が非常に低い可能性があることが認識されています。
This protocol does not limit the maximum message length. Implementers should understand that some machines will be unable to accept excessively long messages. A mechanism is defined in [SIZE] to declare the maximum message size supported.
このプロトコルは、最大メッセージの長さを制限しません。実装者は、一部のマシンが過度に長いメッセージを受け入れることができないことを理解する必要があります。メカニズムは[サイズ]で定義され、サポートされている最大メッセージサイズを宣言します。
The following sections describe the restrictions and additions to Internet mail protocols that are required to be conforming with this VPIM v2 profile. Though various SMTP, ESMTP and MIME features are described here, the implementer is referred to the relevant RFCs for complete details. The table in Appendix A summarizes the protocol details of this profile.
次のセクションでは、このVPIM V2プロファイルに準拠する必要があるインターネットメールプロトコルへの制限と追加について説明します。さまざまなSMTP、ESMTP、およびMIME機能についてはここで説明しますが、実装者は完全な詳細については関連するRFCを参照されます。付録Aの表は、このプロファイルのプロトコルの詳細をまとめたものです。
The voice message interchange format is a profile of the Internet Mail Protocol Suite. Any Internet Mail message containing the format defined in this section is referred to as a VPIM Message in this document. As a result, this document assumes an understanding of the Internet Mail specifications. Specifically, VPIM references components from the message format standard for Internet messages [RFC822], the Multipurpose Internet Message Extensions [MIME1-5], the X.400 gateway specification [X.400], and the delivery status and message disposition notifications [REPORT][DSN][DRPT][STATUS][MDN].
Voiceメッセージインターチェンジ形式は、インターネットメールプロトコルスイートのプロファイルです。このセクションで定義されている形式を含むインターネットメールメッセージは、このドキュメントのVPIMメッセージと呼ばれます。その結果、このドキュメントは、インターネットメールの仕様の理解を前提としています。具体的には、VPIM参照インターネットメッセージのメッセージ形式標準[RFC822]、多目的インターネットメッセージ拡張[MIME1-5]、X.400ゲートウェイ仕様[X.400]、および配信ステータスとメッセージ処分の通知[レポート] [dsn] [drpt] [status] [mdn]。
MIME, introduced in [MIME1], is a general-purpose message body format that is extensible to carry a wide range of body parts. It provides for encoding binary data so that it can be transported over the 7-bit text-oriented SMTP protocol. This transport encoding (denoted by the "Content-Transfer-Encoding:" MIME field) is in addition to the audio encoding required to generate a binary object.
[MIME1]で導入されたMIMEは、幅広い身体部分を運ぶために拡張可能な汎用メッセージボディ形式です。7ビットのテキスト指向SMTPプロトコルで輸送できるように、バイナリデータをエンコードすることを提供します。このトランスポートエンコード（「MIMEフィールド：コンテンツトランスファーエンコード：「MIMEフィールド」で示されています）は、バイナリオブジェクトを生成するために必要なオーディオエンコードに追加されます。
MIME defines two transport-encoding mechanisms to transform binary data into a 7-bit representation, one designed for text-like data ("Quoted-Printable"), and one for arbitrary binary data ("Base64"). While Base64 is dramatically more efficient for audio data, either will work. Where binary transport is available, no transport encoding is needed, and the data can be labeled as "Binary".
MIMEは、2つの輸送エンコードメカニズムを定義して、バイナリデータを7ビット表現に変換します。1つはテキストのようなデータ（「引用プリント可能」）、もう1つは任意のバイナリデータ（「base64」）用に設計されています。Base64はオーディオデータに対して劇的に効率的ですが、どちらも機能します。バイナリトランスポートが利用可能な場合、輸送エンコードは必要ありません。データには「バイナリ」とラベル付けできます。
VPIM addresses SHALL use the RFC 822 format based on the Domain Name System. This naming system has two components: the local part, used for username or mailbox identification; and the host part, used for global machine identification.
VPIMアドレスは、ドメイン名システムに基づいてRFC 822形式を使用するものとします。この命名システムには、ユーザー名またはメールボックスの識別に使用されるローカルパーツの2つのコンポーネントがあります。グローバルマシン識別に使用されるホストパーツ。
The local part of the address shall be a US-ASCII string uniquely identifying a mailbox on a destination system. For voice messaging, the local part SHALL be a printable string containing the mailbox ID of the originator or recipient. While alpha characters and long mailbox identifiers MAY be permitted, short numeric local parts SHOULD be used as most voice mail networks rely on numeric mailbox identifiers to retain compatibility with the limited 10-digit telephone keypad. As a result, some voice messaging systems may only be able to handle a numeric local part. The reception of alphanumeric local parts on these systems may result in the address being mapped to some locally unique (but confusing to the recipient) number or, in the worst case the address could be deleted making the message unreplyable. Additionally, it may be difficult to create messages on these systems with an alphanumeric local part without complex key sequences or some form of directory lookup (see 6). The use of the Domain Name System should be transparent to the user. It is the responsibility of the voice mail machine to lookup the fully-qualified domain name (FQDN) based on the address entered by the user (see 6).
アドレスのローカル部分は、宛先システム上のメールボックスを一意に識別するUS-ASCII文字列でなければなりません。音声メッセージングの場合、ローカル部分は、オリジネーターまたは受信者のメールボックスIDを含む印刷可能な文字列でなければなりません。アルファ文字と長いメールボックス識別子は許可される場合がありますが、ほとんどのボイスメールネットワークは、限られた10桁の電話キーパッドとの互換性を保持するために数値メールボックス識別子に依存しているため、短い数値ローカルパーツを使用する必要があります。その結果、一部の音声メッセージングシステムは、数値ローカル部分のみを処理できる場合があります。これらのシステムでの英数字の局所部品の受信により、アドレスが地元で一意の（ただし、受信者と混乱する）数にマッピングされる可能性があります。最悪の場合、アドレスを削除してメッセージを削除できない可能性があります。さらに、複雑なキーシーケンスまたは何らかの形式のディレクトリルックアップを持たない英数字のローカル部分を使用して、これらのシステムにメッセージを作成することは困難かもしれません（6を参照）。ドメイン名システムの使用は、ユーザーに対して透過的でなければなりません。ユーザーが入力したアドレスに基づいて、完全に資格のあるドメイン名（FQDN）を検索することは、ボイスメールマシンの責任です（6を参照）。
In the absence of a global directory, specification of the local part is expected to conform to international or private telephone numbering plans. It is likely that private numbering plans will prevail and these are left for local definition. However, it is RECOMMENDED that public telephone numbers be noted according to the international numbering plan described in [E.164]. The indication that the local part is a public telephone number is given by a preceding "+" (the "+" would not be entered from a telephone keypad, it is added by the system as a flag). Since the primary information in the numeric scheme is contained by the digits, other character separators (e.g., "-") may be ignored (i.e., to allow parsing of the numeric local mailbox) or may be used to recognize distinct portions of the telephone number (e.g., country code). The specification of the local part of a VPIM address can be split into the four groups described below:
グローバルディレクトリがない場合、ローカルパーツの仕様は、国際または民間の電話番号計画に準拠することが期待されています。プライベート番号の計画が勝ち、これらは現地の定義のために残されている可能性があります。ただし、[e.164]に記載されている国際番号付け計画に従って、公的電話番号に注意することをお勧めします。地元の部分が公的電話番号であるという兆候は、前の「」によって与えられます（「」は電話キーパッドから入力されず、システムによってフラグとして追加されます）。数値スキームの主要な情報は数字に含まれているため、他の文字分離器（「 - 」など）は無視される場合があります（つまり、数値ローカルメールボックスの解析を許可する場合）、または電話の異なる部分を認識するために使用できます。番号（例：国コード）。VPIMアドレスのローカル部分の仕様は、以下の4つのグループに分割できます。
1) mailbox number - for use as a private numbering plan (any number of digits) - e.g., 2722@lucent.com
1) メールボックス番号 - プライベートナンバリングプラン（任意の数字）として使用するため - 例えば2722@lucent.com
2) mailbox number+extension
- for use as a private numbering plan with extensions
any number of digits, use of "+" as separator
- e.g., 2722+111@Lucent.com
3) +international number - for international telephone numbers conforming to E.164 maximum of 15 digits - e.g., +16137637582@vm.nortel.ca
3) 国際番号-E.164最大15桁に適合する国際電話番号の場合 - 例：16137637582@vm.nortel.ca
4) +international number+extension
- for international telephone numbers conforming to E.164
maximum of 15 digits, with an extension (e.g., behind a
PBX) that has a maximum of 15 digits.
- e.g., +17035245550+230@ema.org
Note that this address format is designed to be compatible with current usage within the voice messaging industry. It is not compatible with the addressing formats of RFCs 2303-2304. It is expected that as telephony services become more widespread on the Internet, these addressing formats will converge.
このアドレス形式は、音声メッセージング業界内の現在の使用と互換性があるように設計されていることに注意してください。RFCS 2303-2304のアドレス指定形式と互換性がありません。テレフォニーサービスがインターネット上でより広くなると、これらのアドレス指定形式が収束することが予想されます。
Special addresses to represent the sender are provided for compatibility with the conventions of Internet mail. These addresses do not use numeric local addresses, both to conform to current Internet practice and to avoid conflict with existing numeric addressing plans. Two special addresses are RESERVED for use as follows:
送信者を表す特別なアドレスは、インターネットメールの慣習と互換性があるために提供されます。これらのアドレスは、現在のインターネットの実践に準拠し、既存の数値アドレス計画との競合を回避するために、数値ローカルアドレスを使用していません。次のように使用するために2つの特別なアドレスが予約されています。
postmaster@domain
Postmaster@domain
By convention, a special mailbox named "postmaster" MUST exist on all systems. This address is used for diagnostics and should be checked regularly by the system manager. This mailbox is particularly likely to receive text messages, which is not normal on a voice-processing platform. The specific handling of these messages is an individual implementation choice.
慣習により、「ポストマスター」という名前の特別なメールボックスがすべてのシステムに存在する必要があります。このアドレスは診断に使用され、システムマネージャーが定期的に確認する必要があります。このメールボックスは特にテキストメッセージを受信する可能性が高く、音声処理プラットフォームでは普通ではありません。これらのメッセージの特定の処理は、個別の実装の選択です。
non-mail-user@domain
非mail-user@domain
If a reply to a message is not possible, such as a telephone-answering message, then the special address "non-mail-user" SHOULD be used as the originator's address. Any text name such as "Telephone Answering", or the telephone number if it is available, is permitted. This special address is used as a token to indicate an unreachable originator. A conforming implementation MUST NOT permit a reply to an address from "non-mail-user". For compatibility with the installed base of mail user agents, implementations MUST reject the message when a message addressed to "non-mail-user" is received. The status code for such NDN's is 5.1.1 "Mailbox does not exist".
電話をかけるメッセージなどのメッセージへの返信が不可能な場合、特別なアドレス「非メールユーザー」をオリジネーターのアドレスとして使用する必要があります。「電話応答」などのテキスト名、または利用可能な場合の電話番号は許可されています。この特別なアドレスは、到達不能なオリジネーターを示すためのトークンとして使用されます。適合の実装では、「ノンメールユーザー」からの住所への返信を許可してはなりません。メールユーザーエージェントのインストールされているベースとの互換性については、「ノンメールユーザー」にアドレス指定されたメッセージが受信された場合、実装はメッセージを拒否する必要があります。このようなNDNのステータスコードは5.1.1「メールボックスは存在しません」です。
Example:
例：
From: Telephone Answering <non-mail-user@mycompany.com>
There are many ways to handle distribution list (DL) expansions and none are 'standard'. A VPIM implementation MAY support DLs. Using a simple alias is a behavior closest to what many voice mail systems do today and what is to be used with VPIM messages. A couple of important features that need special care when DLs are used are:
配布リスト（DL）の拡張を処理する方法はたくさんあり、「標準」はありません。VPIM実装はDLSをサポートする場合があります。シンプルなエイリアスを使用することは、多くのボイスメールシステムが今日行っていることや、VPIMメッセージで使用することに最も近い動作です。DLSを使用するときに特別な注意が必要ないくつかの重要な機能は次のとおりです。
Reply to the originator - (Address in the RFC822 "Reply-To:" or "From" field) Errors to the submitter - (Address in the MAIL FROM field of the ESMTP exchange or the "Return-Path:" RFC822 field)
Originatorへの返信 - （RFC822のアドレス "Reply -to："または "from" field）errors to the submister-（ESMTP Exchangeのフィールドまたは「Return -Path：」RFC822フィールドからのメールのアドレス）
Some proprietary voice messaging protocols include only the recipient of the particular copy in the envelope and include no "header fields" except date and per-message features. Most voice messaging systems do not provide for "Header Information" in their messaging queues and only include delivery information. As a result, recipient information MAY be in either the "To:" or "Cc:" header fields. If all recipients cannot be presented then the recipient header fields SHOULD be omitted to indicate that an accurate list of recipients (e.g., for use with a reply-all capability) is not known.
一部の独自の音声メッセージングプロトコルには、エンベロープ内の特定のコピーの受信者のみが含まれており、日付と出気ごとの機能を除いて「ヘッダーフィールド」は含まれません。ほとんどの音声メッセージングシステムは、メッセージングキューに「ヘッダー情報」を提供しておらず、配信情報のみが含まれています。その結果、受信者情報は、「to」または「cc：」ヘッダーフィールドのいずれかにある場合があります。すべての受信者を提示できない場合、受信者ヘッダーフィールドを省略して、受信者の正確なリスト（たとえば、返信機能で使用するため）が不明であることを示す必要があります。
Internet messages contain a header information block. This header block contains information required to identify the sender, the list of recipients, the message send time, and other information intended for user presentation. Except for specialized gateway and mailing list cases, header fields do not indicate delivery options for the transport of messages.
インターネットメッセージには、ヘッダー情報ブロックが含まれています。このヘッダーブロックには、送信者、受信者のリスト、メッセージの送信時間、およびユーザープレゼンテーションを目的としたその他の情報を特定するために必要な情報が含まれています。専門のゲートウェイとメーリングリストのケースを除き、ヘッダーフィールドは、メッセージの輸送の配信オプションを示していません。
Distribution list processors are noted for modifying or adding to the header fields of messages that pass through them. VPIM systems MUST be able to accept and ignore header fields that are not defined here.
配布リストプロセッサは、それらを通過するメッセージのヘッダーフィールドを変更または追加するために注目されています。VPIMシステムは、ここでは定義されていないヘッダーフィールドを受け入れて無視できる必要があります。
The following header lines are permitted for use with VPIM messages:
次のヘッダー行は、VPIMメッセージで使用できます。
SEND RULES
ルールを送信します
The originator's fully qualified domain address (a mailbox address followed by the fully qualified domain name) MUST be present. Systems conforming with this profile SHOULD provide the text personal name of the voice message originator in a quoted phrase, if the name is available. Text names of corporate or positional mailboxes MAY be provided as a simple string. From: [RFC822]
オリジネーターの完全資格のあるドメインアドレス（メールボックスアドレスに続く完全資格のドメイン名）が存在する必要があります。このプロファイルに準拠しているシステムは、名前が利用可能な場合は、引用されたフレーズで音声メッセージオリジネーターのテキストの個人名を提供する必要があります。企業または位置のメールボックスのテキスト名は、単純な文字列として提供される場合があります。From：[RFC822]
Example:
例：
From: "Joe S. User" <12145551212@mycompany.com>
From: Technical Support <611@serviceprovider.com>
From: Non-mail-user@myserver.mycompany.com
From：non-mail-user@myserver.mycompany.com
Voice mail machines may not be able to support separate attributes for the "From:" header fields and the SMTP MAIL FROM, VPIM-conforming systems SHOULD set these values to the same address. Use of addresses different than those present in the "From:" header field address may result in unanticipated behavior.
ボイスメールマシンは、「from」のヘッダーフィールドとSMTPメールの個別の属性をサポートできない場合があります。VPIM-Conformingシステムは、これらの値を同じアドレスに設定する必要があります。「from」に存在するアドレスとは異なるアドレスの使用は、ヘッダーフィールドアドレスが予期しない動作をもたらす可能性があります。
RECEIVE RULES
ルールを受信します
The user listed in the "From:" field MUST be presented in the voice message envelope of the voice messaging system as the originator of the message, though the exact presentation is an implementation decision (e.g., the mailbox ID or the text name MAY be presented). The "From:" address SHOULD be used for replies (see 4.9).
「from：」にリストされているユーザーは、ボイスメッセージングシステムの音声メッセージエンベロープにメッセージの発信者として表示される必要がありますが、正確なプレゼンテーションは実装決定です（たとえば、メールボックスIDまたはテキスト名は提示）。「from：」アドレスは、返信に使用する必要があります（4.9を参照）。
The "To:" field contains the recipient's fully-qualified domain address.
「to：」フィールドには、受信者の完全に資格のあるドメインアドレスが含まれています。
Example:
例：
To: +12145551213@mycompany.com
SEND RULES
ルールを送信します
There MAY be one or more "To:" fields in any message. Systems SHOULD provide a list of recipients only if all recipients are available.
任意のメッセージにフィールドが1つ以上ある場合があります。システムは、すべての受信者が利用可能な場合にのみ、受信者のリストを提供する必要があります。
Systems, such as gateways from protocols or legacy platforms that do not indicate the complete list of recipients, MAY provide a "To:" line. Because these systems cannot accurately enumerate all recipients in the "To:" headers, recipients SHOULD NOT be enumerated.
プロトコルからのゲートウェイや、受信者の完全なリストを示さないレガシープラットフォームなどのシステムは、「to」ラインを提供する場合があります。これらのシステムは、「to」にあるすべての受信者を正確に列挙できないため、ヘッダー、受信者を列挙してはいけません。
RECEIVE RULES
ルールを受信します
Systems conforming to this profile MAY discard the addresses in the "To:" fields if they are unable to store the information. This would, of course, make a reply-to-all capability impossible. If present, the addresses in the "To:" field MAY be used for a reply message to all recipients.
このプロファイルに準拠しているシステムは、情報を保存できない場合は、「to」フィールドのアドレスを破棄する場合があります。もちろん、これにより、すべての返信機能が不可能になります。存在する場合、「to」のアドレスは、すべての受信者への返信メッセージに使用される場合があります。
The "Cc:" field contains additional recipients' fully qualified domain addresses. Many voice mail systems maintain only sufficient envelope information for message delivery and are not capable of storing or providing a complete list of additional recipients.
「CC：」フィールドには、追加の資格のあるドメインアドレスが追加の受信者が含まれています。多くのボイスメールシステムは、メッセージ配信のための十分な封筒情報のみを維持しており、追加の受信者の完全なリストを保存または提供することはできません。
SEND RULES
ルールを送信します
Conforming implementations MAY send "Cc:" lists if all recipients are known at the time of origination. If not, systems SHOULD omit the "Cc:" fields to indicate that the full list of recipients is unknown or otherwise unavailable. The list of disclosed recipients MUST NOT include undisclosed recipients (i.e., those sent via a blind copy).
実装の適合は、すべての受信者が起源時に既知の場合、「CC：」リストを送信する場合があります。そうでない場合、システムは「CC：」フィールドを省略して、受信者の完全なリストが不明または利用できないことを示す必要があります。開示された受信者のリストには、非公開の受信者（つまり、ブラインドコピーを介して送信された受信者）を含めてはなりません。
Example:
例：
Cc: +12145551213@mycompany.com
RECEIVE RULES
ルールを受信します
Systems conforming to this profile MAY add all the addresses in the "Cc:" field to the "To:" field, others MAY discard the addresses in the "Cc:" fields. If a list of "Cc:" addresses is present, these addresses MAY be used for a reply message to all recipients.
このプロファイルに準拠するシステムは、「CC：」のすべてのアドレスを「」に追加する場合があります。「CC：」のリストが存在する場合、これらのアドレスはすべての受信者への返信メッセージに使用される場合があります。
The "Date:" field contains the date and time the message was sent by the originator.
「日付：」フィールドには、メッセージが発信者によって送信された日付と時刻が含まれています。
SEND RULES
ルールを送信します
The sending system MUST report the time the message was sent. The time zone MUST be present and SHOULD be represented in a four-digit time zone offset, such as -0500 for North American Eastern Standard Time. This MAY be supplemented by a time zone name in parentheses, e.g., "-0700 (PDT)".
送信システムは、メッセージが送信された時間を報告する必要があります。タイムゾーンは存在する必要があり、北米東部標準時間の-0500など、4桁のタイムゾーンオフセットで表現する必要があります。これは、括弧内のタイムゾーン名、たとえば「-0700（PDT）」によって補完される場合があります。
Example:
例：
Date: Wed, 28 Jul 96 10:08:49 -0800 (PST)
If the VPIM sender is relaying a message from a system that does not provide a time stamp, the time of arrival at the gateway system SHOULD be used as the date.
VPIM送信者がタイムスタンプを提供しないシステムからのメッセージを中継している場合、ゲートウェイシステムに到着する時間を日付として使用する必要があります。
RECEIVE RULES
ルールを受信します
Conforming implementations SHOULD be able to convert [RFC822] date and time stamps into local time
適合の実装は、[RFC822]日付とタイムスタンプを現地時間に変換できるはずです
The "Sender:" field contains the actual address of the originator if an agent on behalf of the author indicated in the "From:" field sends the message.
「送信者：」フィールドには、著者に代わって「from：」に示されているエージェントがメッセージを送信した場合、オリジネーターの実際のアドレスが含まれています。
SEND RULES
ルールを送信します
This header field MAY be sent by VPIM-conforming systems.
このヘッダーフィールドは、VPIM構成システムによって送信される場合があります。
RECEIVE RULES
ルールを受信します
If the address in the "Sender:" field cannot be preserved in the recipient's message queues or in the next-hop protocol from a gateway, the field MAY be silently discarded.
「送信者：」のアドレスが、受信者のメッセージキューまたはゲートウェイからのネクストホッププロトコルでフィールドを保存できない場合、フィールドは静かに破棄される場合があります。
The "Return-path:" field is added by the final delivering SMTP server. If present, it contains the address from the MAIL FROM parameter of the ESMTP exchange (see [RFC822]). Any error messages resulting from the delivery failure MUST be sent to this address. Note that if the "Return-path:" is null ("<>") (e.g., a call answer message would have no return path) delivery status notifications MUST NOT be sent.
「RETURN-PATH：」フィールドは、SMTPサーバーの最終配信によって追加されます。存在する場合、ESMTP Exchangeのパラメーターからのメールからのアドレスが含まれています（[RFC822]を参照）。配信の失敗から生じるエラーメッセージは、このアドレスに送信する必要があります。「return-path：」がnull（ "<>"）の場合（たとえば、通話回答メッセージには戻りパスがありません）、配信ステータス通知を送信してはなりません。
SEND RULES
ルールを送信します
The originating system MUST NOT add this header.
元のシステムは、このヘッダーを追加してはなりません。
RECEIVE RULES
ルールを受信します
If the receiving system is incapable of storing the return path (or MAIL FROM) to be used for subsequent delivery errors (i.e., it is a gateway to a legacy system or protocol), the receiving system must otherwise ensure that further delivery errors don't happen. Systems that do not support the return path MUST ensure that at the time the message is acknowledged (i.e., when a DSN would be sent), the message is delivered to the recipient's ultimate mailbox. Non-Delivery notifications SHOULD NOT be sent after that final delivery.
受信システムがリターンパス（またはメールからのメール）を保存することができない場合（つまり、レガシーシステムまたはプロトコルへのゲートウェイ）、受信システムは、それ以外の場合は、さらなる配信エラーがないことを確認する必要があります。tが起こります。リターンパスをサポートしないシステムは、メッセージが確認された時点で（つまり、DSNが送信されるとき）、メッセージが受信者の究極のメールボックスに配信されることを保証する必要があります。この最終配達後には、配送のない通知を送信しないでください。
The "Message-Id:" field contains a globally unique per-message identifier.
「Message-ID：」フィールドには、グローバルにユニークな精神ごとの識別子が含まれています。
SEND RULES
ルールを送信します
A globally unique message-id MUST be generated for each message sent from a VPIM-conforming implementation.
VPIM制度の実装から送信されたメッセージごとに、グローバルに一意のメッセージIDを生成する必要があります。
Example:
例：
Message-Id: <12345678@mycompany.com>
RECEIVE RULES
ルールを受信します
When provided in the original message, it MUST be used when sending a MDN. This identifier MAY be used for tracking and auditing. From [RFC822]
元のメッセージで提供される場合、MDNを送信するときに使用する必要があります。この識別子は、追跡と監査に使用できます。[rfc822]から
If present, the "Reply-To:" header provides a preferred address to which reply messages should be sent (see 4.9). Typically, voice mail systems can only support one originator of a message so it is likely that this field will be ignored by the receiving system. From: [RFC822]
存在する場合、「Reply-to」というヘッダーは、返信メッセージを送信する必要がある優先アドレスを提供します（4.9を参照）。通常、ボイスメールシステムはメッセージの1つのオリジネーターのみをサポートできるため、このフィールドは受信システムによって無視される可能性があります。From：[RFC822]
SEND RULES
ルールを送信します
A conforming system SHOULD NOT send a "Reply-To:" header.
適合システムは、「Reply-To」ヘッダーを送信してはなりません。
RECEIVE RULES
ルールを受信します
If a "Reply-To:" field is present, a reply-to-sender message MAY be sent to the address specified (that is, in lieu of the address in the "From:" field). If the receiving system (e.g., multi-protocol gateway) only supports one address for the originator, then the address in the "From:" field MUST be used and the "Reply-To:" field MAY be silently discarded.
「Reply-to」のフィールドが存在する場合、指定されたアドレス（つまり、「from：」フィールドのアドレスの代わりに）に返信者のメッセージを送信することができます。受信システム（たとえば、マルチプロトコルゲートウェイ）がオリジネーターの1つのアドレスのみをサポートする場合、「From」のアドレスを使用する必要があり、「Reply-to」フィールドは静かに破棄される場合があります。
The "Received:" field contains trace information added to the beginning of a RFC822 message by MTAs. This is the only field that may be added by an MTA. Information in this header is useful for debugging when using an US-ASCII message reader or a header-parsing tool. From: [RFC822]
「受信：」フィールドには、MTASによるRFC822メッセージの先頭に追加されたトレース情報が含まれています。これは、MTAによって追加される唯一のフィールドです。このヘッダーの情報は、US-ASCIIメッセージリーダーまたはヘッダー包囲ツールを使用する場合のデバッグに役立ちます。From：[RFC822]
SEND RULES
ルールを送信します
A VPIM-conforming system MUST add a "Received:" field. When acting as a gateway, information about the system from which the message was received SHOULD be included.
VPIM-Conformingシステムは、「受信：」フィールドを追加する必要があります。ゲートウェイとして機能する場合、メッセージが受信されたシステムに関する情報を含める必要があります。
RECEIVE RULES
ルールを受信します
A VPIM-conforming system MUST NOT remove any "Received:" fields when relaying messages to other MTAs or gateways. These header fields MAY be ignored or deleted when the message is received at the final destination.
VPIM構成システムは、他のMTAまたはゲートウェイにメッセージを中継するときに「受信：受信：」フィールドを削除してはなりません。これらのヘッダーフィールドは、最終目的地でメッセージを受信したときに無視または削除される場合があります。
The "MIME-Version:" field MUST be present to indicate that the message conforms to [MIME1-5]. Systems conforming with this specification SHOULD include a comment with the words "(Voice 2.0)". [VPIM1] defines an earlier version of this profile and uses the token (Voice 1.0). Example:
「mime-version：」は、メッセージが[mime1-5]に適合することを示すために存在する必要があります。この仕様に準拠したシステムには、「（Voice 2.0）」という言葉のコメントが含まれている必要があります。[VPIM1]は、このプロファイルの以前のバージョンを定義し、トークンを使用します（Voice 1.0）。例：
MIME-Version: 1.0 (Voice 2.0)
マイムバージョン：1.0（音声2.0）
This identifier is intended for information only and SHOULD NOT be used to semantically identify the message as being a VPIM message. Instead, the presence of the multipart/voice-message content type defined in section 18.2 SHOULD be used if identification is necessary.
この識別子は情報のみを目的としているため、メッセージをVPIMメッセージとして意味的に識別するために使用しないでください。代わりに、識別が必要な場合は、セクション18.2で定義されたマルチパート/音声メッセージコンテンツタイプの存在を使用する必要があります。
The "Content-Type:" header MUST be present to declare the type of content enclosed in the message. The typical top-level content in a VPIM Message SHOULD be Multipart/Voice-Message. The allowable contents are detailed starting in section 4.4 of this document. From: [MIME2]
「コンテンツタイプ：」ヘッダーは、メッセージに囲まれたコンテンツのタイプを宣言するために存在する必要があります。VPIMメッセージの典型的なトップレベルコンテンツは、マルチパート/音声メッセージでなければなりません。許容コンテンツは、このドキュメントのセクション4.4から詳細に説明されています。From：[mime2]
Because Internet mail was initially specified to carry only 7-bit US-ASCII text, it may be necessary to encode voice and fax data into a representation suitable for that environment. The "Content-Transfer-Encoding:" header describes this transformation if it is needed.
インターネットメールは最初に7ビットのUS-ASCIIテキストのみを搭載するように指定されていたため、音声とFAXデータをその環境に適した表現にエンコードする必要がある場合があります。「コンテンツトランスファーエンコード：」ヘッダーは、必要な場合にこの変換について説明します。
SEND RULES
ルールを送信します
An implementation in conformance with this profile SHOULD send audio and/or facsimile data in "Binary" form when binary message transport is available (see section 5). When binary transport is not available, implementations MUST encode the audio and/or facsimile data as "Base64".
このプロファイルに準拠した実装では、バイナリメッセージトランスポートが利用可能になったときに、「バイナリ」フォームでオーディオおよび/またはファクシミリデータを送信する必要があります（セクション5を参照）。バイナリトランスポートが利用できない場合、実装はオーディオおよび/またはファクシミリデータを「base64」としてエンコードする必要があります。
RECEIVE RULES
ルールを受信します
Conforming implementations MUST recognize and decode the standard encodings, "Binary" (when binary support is available), "7bit, "8bit", "Base64" and "Quoted-Printable" per [MIME1]. The detection and decoding of "Quoted-Printable", "7bit", and "8bit" MUST be supported in order to meet MIME requirements and to preserve interoperability with the fullest range of possible devices.
適合の実装は、標準のエンコーディング「バイナリ」（バイナリサポートが利用可能な場合）、「7ビット」、「8ビット」、「base64」、[mime1]ごとに「引用されている」という標準エンコーディングを認識してデコードする必要があります。印刷可能な「7ビット」、および「8ビット」は、MIMEの要件を満たし、可能なデバイスの最大限と相互運用性を維持するためにサポートする必要があります。
The "Sensitivity:" field, if present, indicates the requested privacy level. If no privacy is requested, this field is omitted. The header definition is as follows:
「感度：」フィールドは、存在する場合、要求されたプライバシーレベルを示します。プライバシーが要求されない場合、このフィールドは省略されています。ヘッダー定義は次のとおりです。
Sensitivity := "Sensitivity" ":" Sensitivity-value
Sensitivity-value := "Personal" / "Private" / "Company-Confidential"
SEND RULES
ルールを送信します
A VPIM-conforming implementation MAY include this header to indicate the sensitivity of a message. If a user marks a message "Private", a conforming implementation MUST send only the "Private" sensitivity level. There are no VPIM-specific semantics defined for the values "Personal" or "Company-Confidential". A conforming implementation SHOULD NOT send the values "Personal" or "Company-Confidential". If the message is of "Normal" sensitivity, this field SHOULD be omitted. From: [X.400] RECEIVE RULES
VPIMを構成する実装には、メッセージの感度を示すこのヘッダーが含まれる場合があります。ユーザーが「プライベート」というメッセージをマークする場合、適合の実装は「プライベート」感度レベルのみを送信する必要があります。「個人」または「会社の自信」の値に対して定義されたVPIM固有のセマンティクスはありません。適合の実装は、「個人」または「会社の自信」の値を送信してはなりません。メッセージが「通常の」感度の場合、このフィールドは省略する必要があります。From：[x.400]ルールを受信します
If a "Sensitivity:" field with a value of "Private" is present in the message, a conforming system MUST prohibit the recipient from forwarding this message to any other user. A conforming system, however, SHOULD allow the responder to reply to a sensitive message, but SHOULD NOT include the original message content. The responder MAY set the sensitivity of the reply message.
「sensitivity：」の値が「プライベート」のフィールドがメッセージに存在する場合、適合システムは受信者がこのメッセージを他のユーザーに転送することを禁止する必要があります。ただし、適合システムは、応答者が機密メッセージに返信できるようにする必要がありますが、元のメッセージコンテンツを含めるべきではありません。応答者は、返信メッセージの感度を設定する場合があります。
A receiving system MAY ignore sensitivity values of "Personal" and "Company Confidential".
受信システムは、「個人」および「会社の機密」の感度値を無視する場合があります。
If the receiving system does not support privacy and the sensitivity is "Private", a negative delivery status notification MUST be sent to the originator with the appropriate status code (5.6.0) "Other or undefined protocol status" indicating that privacy could not be assured. The message contents SHOULD be returned to the sender to allow for a voice context with the notification. A non-delivery notification to a private message SHOULD NOT be tagged private since it will be sent to the originator. From: [X.400]
受信システムがプライバシーをサポートせず、感度が「プライベート」である場合、適切なステータスコード（5.6.0）「その他または未定義のプロトコルステータス」を持つネガティブ配信ステータス通知をオリジネーターに送信する必要があります。保証。メッセージの内容は、通知との音声コンテキストを可能にするために、送信者に返品する必要があります。プライベートメッセージへの配信のない通知は、オリジネーターに送信されるため、プライベートにタグを付けてはなりません。From：[x.400]
A message with no privacy explicitly noted (i.e., no header) or with "Normal" sensitivity has no special treatment.
プライバシーが明示的に記録されていない（つまり、ヘッダーなし）、または「通常の」感度のメッセージには特別な治療はありません。
Indicates the requested importance to be given by the receiving system. If no special importance is requested, this header MAY be omitted and the value of the absent header assumed to be "normal". From: [X.400]
受信システムによって与えられる要求された重要性を示します。特別な重要性が要求されない場合、このヘッダーは省略され、欠席ヘッダーの値は「正常」であると想定されます。From：[x.400]
Importance := "Importance" ":" importance-value
Importance-value := "low" / "normal" / "high"
SEND RULES
ルールを送信します
Conforming implementations MAY include this header to indicate the importance of a message.
適合実装には、メッセージの重要性を示すためにこのヘッダーが含まれる場合があります。
RECEIVE RULES
ルールを受信します
If the receiving system does not support "Importance:", the attribute MAY be silently dropped.
受信システムが「重要性：」をサポートしていない場合、属性は静かに削除される場合があります。
The "Subject:" field is often provided by email systems but is not widely supported on voice mail platforms. From: [RFC822]
「件名：」フィールドは、多くの場合、電子メールシステムによって提供されますが、ボイスメールプラットフォームでは広くサポートされていません。From：[RFC822]
SEND RULES
ルールを送信します
For compatibility with text-based mailbox interfaces, a text subject field SHOULD be generated by a conforming implementation. It is RECOMMENDED that voice-messaging systems that do not support any text user interfaces (e.g., access only by a telephone) insert a generic subject header of "VPIM Message" or "Voice Message" for the benefit of GUI-enabled recipients.
テキストベースのメールボックスインターフェイスと互換性があるため、適合実装によってテキストサブジェクトフィールドを生成する必要があります。テキストユーザーインターフェイスをサポートしていない音声メッセージングシステム（たとえば、電話のみでアクセス）をサポートすることをお勧めします。ガイ対応の受信者の利益のために、「VPIMメッセージ」または「音声メッセージ」の一般的な件名ヘッダーを挿入することをお勧めします。
RECEIVE RULES
ルールを受信します
It is anticipated that many voice-only systems will be incapable of storing the subject line. The subject MAY be discarded by a receiving system.
多くの音声専用システムは、件名を保存できないと予想されます。被験者は、受信システムによって廃棄される場合があります。
This field MAY be present to facilitate the text identification of these body parts in simple email readers. Any values may be used.
このフィールドは、単純な電子メールリーダーでこれらの身体部分のテキスト識別を促進するために存在する場合があります。任意の値を使用できます。
Example:
例：
Content-Description: Big Telco Voice Message
コンテンツデスプト：ビッグテルコ音声メッセージ
SEND RULES
ルールを送信します
This field MAY be added to a voice body part to offer a freeform description of the voice content. It is useful to incorporate the values for Content-Disposition with additional descriptions. For example, this can be used to indicate product name or transcoding records.
このフィールドは、音声コンテンツのフリーフォームの説明を提供するために、音声体の部分に追加される場合があります。追加の説明を使用して、コンテンツディスポジションの値を組み込むと便利です。たとえば、これは製品名またはトランスコーディングレコードを示すために使用できます。
RECEIVE RULES
ルールを受信します
This field MAY be displayed to the recipient. However, since it is only informative it MAY be ignored.
このフィールドは、受信者に表示される場合があります。ただし、有益であるため、無視される可能性があります。
This field MUST be present to allow the parsable identification of body parts within a VPIM voice message. This is especially useful if, as is typical, more than one Audio/* body occurs within a single level (e.g., Multipart/Voice-Message). Since a VPIM voice message is intended to be automatically played in the order in which the audio contents occur, the audio contents MUST always be of disposition inline. However, it is still useful to include a filename value, so this SHOULD be present if this information is available. From: [DISP]
このフィールドは、VPIM音声メッセージ内の身体部分の識別可能な識別を可能にするために存在する必要があります。これは、典型的であるように、単一のレベル（マルチパート/音声メッセージなど）内で複数のオーディオ/*ボディが発生する場合に特に便利です。VPIM音声メッセージは、オーディオコンテンツが発生する順序で自動的に再生されることを目的としているため、オーディオコンテンツは常にインラインである必要があります。ただし、ファイル名値を含めることは依然として便利であるため、この情報が利用可能な場合はこれが存在するはずです。From：[disp]
SEND RULES
ルールを送信します
In order to distinguish between the various types of audio contents in a VPIM voice message a new disposition parameter "voice" is defined with IANA (see section 18.1) with the parameter values below to be used as appropriate:
VPIM音声メッセージ内のさまざまなタイプのオーディオコンテンツを区別するために、新しい気質パラメーター「音声」はIANA（セクション18.1を参照）で定義され、以下のパラメーター値が必要に応じて使用されます。
Audio-Type := "voice" "=" Audio-type-value
Audio-type-value := "Voice-Message" / "Voice-Message-Notification" /
"Originator-Spoken-Name" /"Recipient-Spoken-Name" /"Spoken-Subject"
Voice-Message - the primary voice message, Voice-Message-Notification - a spoken delivery notification or spoken disposition notification, Originator-Spoken-Name - the spoken name of the originator, Recipient-Spoken-Name - the spoken name of the recipient(s) if available to the originator Spoken-Subject- the spoken subject of the message, typically spoken by the originator
音声メッセージ - プライマリボイスメッセージ、音声メッセージノーティフィケーション - 音声配信通知または音声処分通知、オリジネーターのスポークン名 - オリジネーターの話された名前、受信者のスポーン名 - 受信者の話された名前（s）発信者が話された人物が利用できる場合 - メッセージの話された主題、通常はオリジネーターが話している
Note that there SHOULD only be one instance of each of these types of audio contents per message level. Additional instances of a given type (i.e., parameter value) MAY occur within an attached forwarded or reply voice message. If there are multiple recipients for a given message, recipient-spoken-name MUST NOT be used.
メッセージレベルごとに、これらのタイプのオーディオコンテンツのそれぞれに1つのインスタンスしかない必要があることに注意してください。特定のタイプの追加インスタンス（つまり、パラメーター値）は、添付された転送または返信音声メッセージ内で発生する場合があります。特定のメッセージに複数の受信者がいる場合、受信者が演じた名前を使用してはなりません。
RECEIVE RULES
ルールを受信します
Implementations SHOULD use this header. However, those that do not understand the "voice" parameter (or the "Content-Disposition:" header) can safely ignore it, and will present the audio body parts in order (but will not be able to distinguish between them). If more than one instance of the "voice" parameter type value is encountered at one level (e.g., multiple 'Voice-Message' tagged contents) then they SHOULD be presented together.
実装はこのヘッダーを使用する必要があります。ただし、「音声」パラメーター（または「コンテンツディスポジション：」ヘッダー）を理解していない人は、それを安全に無視でき、オーディオボディの部分を順番に表示します（ただし、それらを区別することはできません）。「Voice」パラメータータイプの値の複数のインスタンスが1つのレベル（たとえば、複数の「Voice-Message」にタグ付きコンテンツ）で発生する場合、それらを一緒に提示する必要があります。
The "Content-Duration:" header provides an indication of the audio length in seconds of the segment.
「コンテンツ期間：」ヘッダーは、セグメントの秒単位でオーディオの長さを示しています。
Example:
例：
Content-Duration: 33
コンテンツ期間：33
SEND RULES
ルールを送信します
This field MAY be present to allow the specification of the length of the audio body part in seconds.
このフィールドは、秒単位でオーディオボディパーツの長さの仕様を許可するために存在する場合があります。
RECEIVE RULES
ルールを受信します
The use of this field on reception is a local implementation issue. From: [DUR]
受信でこのフィールドを使用することは、ローカルの実装の問題です。From：[dur]
4.3.4. Content-Language:
4.3.4. Content-Language：
This field MAY be present to allow the specification of the spoken language of the audio body part. The encoding is defined in [LANG].
このフィールドは、オーディオボディパーツの音声言語の仕様を許可するために存在する場合があります。エンコーディングは[Lang]で定義されています。
Example for UK English:
英国英語の例：
Content-Language: en-UK
Content-Language：en-uk
SEND RULES
ルールを送信します
A sending system MAY add this field to indicate the language of the voice. The determination of this (e.g., automated or user-selected) is a local implementation issue.
送信システムは、音声の言語を示すためにこのフィールドを追加する場合があります。これの決定（たとえば、自動化またはユーザー選択）は、ローカルの実装の問題です。
RECEIVE RULES
ルールを受信します
The use of this field on reception is a local implementation issue. It MAY be used as a hint to the recipient (e.g., end-user or an automated translation process) as to the language of the voice message.
受信でこのフィールドを使用することは、ローカルの実装の問題です。音声メッセージの言語に関して、受信者（例：エンドユーザーや自動翻訳プロセスなど）のヒントとして使用できます。
The content types described in this section are identified for use within the Multipart/Voice-Message content. This content is referred to as a "VPIM message" in this document and is the fundamental part of a "VPIM message".
このセクションで説明するコンテンツタイプは、MultiPart/Voice-Messageコンテンツ内で使用するために識別されます。このコンテンツは、このドキュメントの「VPIMメッセージ」と呼ばれ、「VPIMメッセージ」の基本的な部分です。
Only the contents profiled can be sent within a VPIM voice message construct (i.e., the Multipart/Voice-Message content type) to form a simple or a more complex structure (several examples are given in Appendix B). The presence of other contents within a VPIM voice message is not permitted. In the absence of a bilateral agreement, conforming implementations MUST NOT create a message containing prohibited contents. In the spirit of liberal acceptance, a conforming implementation MAY accept and render prohibited content. Systems unable to accept or render prohibited contents MAY discard the prohibited contents as necessary to deliver the acceptable content. When multiple contents are present within the Multipart/Voice-Message, they SHOULD be presented to the user in the order that they appear in the message.
プロファイルされたコンテンツのみをVPIMボイスメッセージコンストラクト（つまり、マルチパート/音声メッセージコンテンツタイプ）内で送信して、単純またはより複雑な構造を形成できます（付録Bにはいくつかの例が示されています）。VPIM音声メッセージ内の他のコンテンツの存在は許可されていません。二国間契約がない場合、実装を適合させることは、禁止されたコンテンツを含むメッセージを作成してはなりません。リベラルな受け入れの精神では、適合した実装は、コンテンツを禁止することを受け入れ、レンダリングする場合があります。禁止されているコンテンツを受け入れるかレンダリングできないシステムは、許容可能なコンテンツを配信するために必要に応じて禁止されたコンテンツを破棄する場合があります。複数のコンテンツがMultiPart/Voice-Message内に存在する場合、メッセージに表示される順序でユーザーに提示する必要があります。
Some deployed implementations based on a common interpretation of the original VPIM v2 specification reject messages with prohibited content rather than discard the unsupported contents. For interoperability with these systems, it is especially important that prohibited contents not be sent within a Multipart/Voice-Message.
元のVPIM V2仕様の一般的な解釈に基づいて展開されたいくつかの展開された実装は、サポートされていないコンテンツを破棄するのではなく、禁止されたコンテンツでメッセージを拒否します。これらのシステムとの相互運用性のために、禁止されているコンテンツをマルチパート/音声メッセージ内で送信しないことが特に重要です。
This MIME multipart structure provides a mechanism for packaging a voice message into one container that is tagged as VPIM v2 conforming. The sub-type is identical in semantics and syntax to multipart/mixed, as defined in [MIME2]. As such, it may be safely interpreted as a multipart/mixed by systems that do not understand the sub-type (only the identification as a voice message would be lost).
このMIMEマルチパート構造は、VPIM V2に適合するとしてタグ付けされた1つのコンテナに音声メッセージをパッケージ化するメカニズムを提供します。サブタイプは、[MIME2]で定義されているように、セマンティクスとマルチパート/混合の構文で同一です。そのため、サブタイプを理解していないシステムによってマルチパート/混合として安全に解釈される場合があります（音声メッセージとしての識別のみが失われる）。
In addition to the MIME required boundary parameter, a version parameter is also required for this sub-type. This is to distinguish this refinement of the sub-type from the previous definition in [VPIM1]. The value of the version parameter is "2.0" if the content conforms to the requirements of this specification. Should there be further revisions of this content type, there MUST be backwards compatibility (i.e., systems implementing version n can read version 2, and systems implementing version 2 can read version 2 contents within a version n).
必要な境界パラメーターに加えて、このサブタイプにはバージョンパラメーターも必要です。これは、[VPIM1]の以前の定義とサブタイプのこの改良を区別することです。コンテンツがこの仕様の要件に準拠している場合、バージョンパラメーターの値は「2.0」です。このコンテンツタイプのさらなる改訂がある場合、逆方向の互換性が必要です（つまり、バージョンnを実装するシステムはバージョン2を読み取ることができ、バージョン2を実装するシステムはバージョンn内のバージョン2のコンテンツを読み取ることができます）。
SEND RULES
ルールを送信します
The Multipart/Voice-Message content-type MUST only contain the profiled media and content types specified in this section (i.e., Audio/*, Image/*, and Message/RFC822). The most common will be: spoken name, spoken subject, the message itself, and an attached fax. Forwarded messages are created by simply using the Message/RFC822 construct.
MultiPart/Voice-Message Content-Typeには、このセクションで指定されているプロファイルされたメディアとコンテンツタイプ（つまり、Audio/*、Image/*、およびMessage/RFC822）のみを含める必要があります。最も一般的なのは、話された名前、音声主題、メッセージ自体、添付のFAXです。転送されたメッセージは、メッセージ/RFC822コンストラクトを使用するだけで作成されます。
Conformant implementations MUST use Multipart/Voice-Message in a VPIM message. In most cases, this Multipart/Voice-Message Content-Type will be the top level but may be included within a Message/RFC822 if the message is forwarded or within a multipart/mixed when more than one message is being forwarded.
適合実装は、VPIMメッセージでMultiPart/Voice-Messageを使用する必要があります。ほとんどの場合、このMultiPart/Voice-Message Content-Typeはトップレベルになりますが、メッセージが転送された場合はメッセージ/RFC822に含まれる場合があります。
RECEIVE RULES
ルールを受信します
Conformant implementations MUST recognize the Multipart/Voice-Message content (whether it is a top-level content or contained in a Multipart/Mixed) and MUST be able to separate the contents (e.g., spoken name or spoken subject).
コンフォーマントの実装は、マルチパート/音声メッセージコンテンツ（トップレベルのコンテンツであるか、マルチパート/混合に含まれているか）を認識する必要があり、コンテンツを分離することができなければなりません（たとえば、音声名または音声科目）。
The semantic of Multipart/Voice-Message (defined in section 18.2) is identical to Multipart/Mixed and may be interpreted as that by systems that do not recognize this content-type.
MultiPart/Voice-Messageのセマンティック（セクション18.2で定義）は、MultiPart/Mixedと同一であり、このコンテンツタイプを認識していないシステムによって解釈される場合があります。
SEND RULES
ルールを送信します
MIME requires support of the Message/RFC822 message encapsulation body part. This body part SHOULD be used within a Multipart/Voice-Message to forward complete messages (see 4.8) or to reply with original content (see 4.9). From: [MIME2]
MIMEには、メッセージ/RFC822メッセージカプセル化本体パーツのサポートが必要です。このボディの部分は、マルチパート/音声メッセージ内で使用して、完全なメッセージ（4.8を参照）を転送するか、元のコンテンツ（4.9を参照）で返信する必要があります。From：[mime2]
RECEIVE RULES
ルールを受信します
The receiving system MUST accept this format and SHOULD treat this attachment as a forwarded message. The receiving system MAY flatten the forwarding structure (i.e., remove this construct to leave multiple voice contents or even concatenate the voice contents to fit in a recipient's mailbox), if necessary.
受信システムはこの形式を受け入れる必要があり、この添付ファイルを転送されたメッセージとして扱う必要があります。受信システムは、転送構造を平坦化する場合があります（つまり、この構成要素を削除して、複数の音声内容を残したり、音声内容を連結して受信者のメールボックスに適合させたりします）。
SEND RULES
ルールを送信します
An implementation conforming to this profile MUST send Audio/32KADPCM by default for voice [ADPCM]. This encoding is a moderately-compressed encoding with a data rate of 32 kbits/second using moderate processing resources. Typically, this body contains several minutes of message content; however, if used for spoken name or subject the content is expected to be considerably shorter (i.e., about 5 and 10 seconds respectively).
このプロファイルに準拠した実装は、boice [adpcm]に対してデフォルトでaudio/32kadpcmを送信する必要があります。このエンコードは、中程度の処理リソースを使用して32 kbit/秒のデータレートで適度に圧縮されたエンコードです。通常、このボディには数分間のメッセージコンテンツが含まれています。ただし、音声名または被験者に使用される場合、コンテンツはかなり短くなると予想されます（つまり、それぞれ約5秒と10秒）。
RECEIVE RULES
ルールを受信します
Receivers MUST be able to accept and decode Audio/32KADPCM. If an implementation can only handle one voice body, then multiple voice bodies (if present) SHOULD be concatenated, and MUST NOT be discarded. If concatenated, the contents SHOULD be in the same order they appeared in the multipart.
受信者は、Audio/32KADPCMを受け入れてデコードできる必要があります。実装が1つの音声ボディのみを処理できる場合、複数の音声体（存在する場合）を連結する必要があり、廃棄しないでください。連結した場合、内容はマルチパートに表示されたのと同じ順序である必要があります。
A common image encoding for facsimile, known as TIFF-F, is a derivative of the Tag Image File Format (TIFF) and is described in several documents. For the purposes of VPIM, the F Profile of TIFF for Facsimile (TIFF-F) is defined in [TIFF-F], and the Image/TIFF MIME content-type is defined in [TIFFREG]. While there are several formats of TIFF, only TIFF-F is profiled for use within Multipart/Voice-Message. Further, since the TIFF-F file format is used in a store-and-forward mode with VPIM, the image MUST be encoded so that there is only one image strip per facsimile page.
TIFF-Fとして知られるFACSIMILE向けの一般的な画像は、タグイメージファイル形式（TIFF）の派生物であり、いくつかのドキュメントで説明されています。VPIMの目的のために、ファクシミリ（TIFF-F）のTIFFのFプロファイルは[TIFF-F]で定義され、画像/TIFF MIMEコンテンツタイプは[Tiffreg]で定義されています。TIFFにはいくつかの形式がありますが、TIFF-FのみがMultiPart/Voice-Messageで使用するようにプロファイルされます。さらに、TIFF-Fファイル形式はVPIMを使用したストアアンドフォワードモードで使用されるため、ファクシミリページごとに1つの画像ストリップのみがあるように、画像をエンコードする必要があります。
SEND RULES
ルールを送信します
All VPIM implementations that support facsimile MUST generate TIFF-F compatible facsimile contents in the Image/TIFF subtype using the application=faxbw encoding by default. If the VPIM message is a voice- annotated fax, the implementation SHOULD send this fax content in Multipart/Voice-Message. If the message is a simple fax, an implementation MAY send it without using the Multipart/Voice-Message to be more compatible with fax-only (RFC 2305) implementations.
ファクシミリをサポートするすべてのVPIM実装は、デフォルトでアプリケーション= FAXBWエンコードを使用して、画像/TIFFサブタイプでTIFF-F互換ファクシミリコンテンツを生成する必要があります。VPIMメッセージが音声注釈付きファックスである場合、実装はこのファックスコンテンツをMultiPart/Voice-Messageで送信する必要があります。メッセージが単純なFAXである場合、実装は、MultiPart/Voice-Messageを使用せずにFaxのみ（RFC 2305）の実装と互換性がある場合があります。
While any valid MIME body header MAY be used (e.g., Content-Disposition to indicate the filename), none are specified to have special semantics for VPIM and MAY be ignored. Note that the content-type parameter application=faxbw MUST be included in outbound messages.
有効なMIMEボディヘッダーは使用される場合がありますが（たとえば、ファイル名を示すコンテンツディスポジション）、VPIMの特別なセマンティクスを持つように指定されているものはなく、無視される場合があります。コンテンツタイプのパラメーターアプリケーション= FAXBWは、アウトバウンドメッセージに含める必要があることに注意してください。
RECEIVE RULES
ルールを受信します
Not all VPIM systems support fax, but all SHOULD accept it within the multipart/voice-message. Within a Multipart/Voice-Message, a receiving system that cannot render fax content SHOULD accept the voice content of a VPIM message and discard the fax content. Outside a Multipart/Voice-Message, a recipient system MAY reject (with appropriate NDN) the entire message if it cannot store or is not capable of rendering a message with fax attachments. VPIM conforming systems MAY support fax outside of (or without) the Multipart/Voice-Message.
すべてのVPIMシステムがFAXをサポートするわけではありませんが、すべてがMultiPart/Voice-Message内でそれを受け入れる必要があります。MultiPart/Voice-Message内では、FAXコンテンツをレンダリングできない受信システムは、VPIMメッセージの音声コンテンツを受け入れ、FAXコンテンツを破棄する必要があります。MultiPart/Voice-Messageの外では、受信者システムは、FAXの添付ファイルでメッセージを保存できない、またはメッセージをレンダリングできない場合、メッセージ全体を（適切なNDNで）拒否する場合があります。VPIM適合システムは、マルチパート/音声メッセージ以外のFAXをサポートする場合があります。
Some deployed implementations based on a common interpretation of the original VPIM V2 specification reject messages with fax content within the Multipart/Voice-Message rather than discard the unsupported contents. These systems will return the message to the sender with an NDN indicating lack of support for fax.
元のVPIM V2仕様の一般的な解釈に基づいて、サポートされていないコンテンツを破棄するのではなく、MultiPart/Voice-Message内のFAXコンテンツを使用してメッセージを拒否しました。これらのシステムは、FAXのサポートがないことを示すNDNで送信者にメッセージを返します。
The following MIME contents (with the exception of multipart/mixed in section 4.5.1) MAY be included within a multipart/voice message. Other contents MUST NOT be included. Their handling is a local implementation issue. Multipart/mixed is included to promote interoperability with a wider range of systems and also to allow the creation of more complex multimedia messages (with a VPIM message as one part).
次のMIMEコンテンツ（セクション4.5.1のマルチパート/混合を除く）は、マルチパート/音声メッセージに含まれる場合があります。他のコンテンツを含めてはなりません。それらの取り扱いはローカルの実装の問題です。MultiPart/Mixedは、より広い範囲のシステムで相互運用性を促進し、より複雑なマルチメディアメッセージを作成できるようにするために含まれています（VPIMメッセージを1つの部分として）。
This common MIME content-type allows the enclosing of several body parts in a single message.
この一般的なMIMEコンテンツタイプにより、単一のメッセージにいくつかの身体部分を囲むことができます。
SEND RULES
ルールを送信します
A VPIM voice message (i.e., multipart/voice-message) MAY be included within a message with a Multipart/Mixed top-level content type. Typically, this would only be used when mixing non-voice and non-fax contents with a voice message.
VPIM音声メッセージ（つまり、MultiPart/Voice-Message）は、マルチパート/混合トップレベルのコンテンツタイプのメッセージに含まれる場合があります。通常、これは、音声メッセージと音声メッセージと声の内容を混合する場合にのみ使用されます。
RECEIVE RULES
ルールを受信します
Such a message is not itself a VPIM message and the handling of such a construct is outside the scope of the VPIM profile. However, an the spirit of liberal acceptance, a conforming implementation MUST accept and render a VPIM voice message contained in a Multipart/Mixed.
このようなメッセージ自体はVPIMメッセージではなく、そのようなコンストラクトの処理はVPIMプロファイルの範囲外です。ただし、リベラルな受け入れの精神である適合実装は、マルチパート/ミックスに含まれるVPIM音声メッセージを受け入れてレンダリングする必要があります。
SEND RULES
ルールを送信します
This content was profiled in the original specification of VPIM v2 as a means of transporting contact information from the sender to the recipient. This usage did not find widespread adoption and is no longer a feature of VPIM V2. Conforming implementations SHOULD NOT send the Text/Directory content type.
このコンテンツは、送信者から受信者に連絡先情報を輸送する手段として、VPIM V2の元の仕様でプロファイルされました。この使用は、広範囲にわたる採用を見出さず、VPIM V2の機能ではなくなりました。実装の適合は、テキスト/ディレクトリコンテンツタイプを送信しないでください。
RECEIVE RULES
ルールを受信します
For compatibility with an earlier specification of VPIM v2, the Text/Directory content type MUST be accepted by a conforming implementation, but need not be stored, processed, or rendered to the recipient.
VPIM V2の以前の仕様との互換性のために、テキスト/ディレクトリコンテンツのタイプは、適合の実装によって受け入れられる必要がありますが、受信者に保存、処理、またはレンダリングする必要はありません。
Use of any other encoding except the required codecs reduces interoperability in the absence of explicit knowledge about the capabilities of the recipient. A conforming implementation SHOULD NOT use any other encoding unless a unique identifier is registered with the IANA prior to use (see [MIME4]). The voice encodings SHOULD be registered as subtypes of Audio. The fax encodings SHOULD be registered as subtypes of Image.
必要なコーデックを除く他のエンコーディングを使用すると、受信者の能力に関する明示的な知識がない場合に相互運用性が低下します。適合実装は、使用前に一意の識別子がIANAに登録されていない限り、他のエンコードを使用しないでください（[MIME4]を参照）。音声エンコーディングは、オーディオのサブタイプとして登録する必要があります。FAXエンコーディングは、画像のサブタイプとして登録する必要があります。
SEND RULES
ルールを送信します
Proprietary voice encoding formats or other standard formats SHOULD NOT be sent under this profile unless the sender has a reasonable expectation that the recipient will accept the encoding. In practice, this requires explicit per-destination configuration information maintained either in a directory, personal address book, or gateway configuration tables.
独自の音声エンコード形式またはその他の標準形式は、受信者がエンコードを受け入れるという合理的な期待を持っている場合を除き、このプロファイルの下で送信しないでください。実際には、これには、ディレクトリ、個人のアドレス帳、またはゲートウェイ構成テーブルのいずれかで維持される明示的な設定構成情報が必要です。
RECEIVE RULES
ルールを受信します
Systems MAY accept other Audio/* or Image/* content types if they can decode them. Systems which receive Audio/* or Image/* content types which they are unable to deposit or unable to render MUST return the message (and SHOULD include the original content) to the originator with an NDN indicating media not supported.
システムは、他のAudio/*またはImage/*コンテンツタイプをデコードできる場合は、受け入れる場合があります。Audio/*またはImage/*コンテンツタイプを入金できない、またはレンダリングできないシステムは、サポートされていないメディアを示すNDNを使用して、メッセージを元のコンテンツに戻す（および元のコンテンツを含める必要があります）。
MIME requires support of the basic Text/Plain content type (with the US-ASCII character set). This content type has limited applicability within the voice-messaging environment. However, because VPIM is a MIME profile, MIME requirements SHOULD be met.
MIMEには、基本的なテキスト/プレーンコンテンツタイプ（US-ASCII文字セットを使用）のサポートが必要です。このコンテンツタイプは、音声メッセージ環境内での適用性が限られています。ただし、VPIMはMIMEプロファイルであるため、MIME要件を満たす必要があります。
SEND RULES
ルールを送信します
Conforming VPIM implementations SHOULD NOT send the Text/Plain content-type. Implementations MAY send the Text/Plain content-type outside the Multipart/Voice-Message.
適合VPIMの実装は、テキスト/プレーンコンテンツタイプを送信しないでください。実装は、マルチパート/音声メッセージの外側にテキスト/プレーンコンテンツタイプを送信する場合があります。
RECEIVE RULES
ルールを受信します
Within a Multipart/Voice-Message, the Text/Plain content-type MAY be dropped from the message, if necessary, to deliver the audio/fax components. The recipient SHOULD NOT reject the entire message if the text component cannot be accepted or rendered.
MultiPart/Voice-Message内で、テキスト/プレーンコンテンツタイプは、必要に応じて、音声/FAXコンポーネントを配信するためにメッセージから削除される場合があります。テキストコンポーネントを受け入れたりレンダリングできない場合、受信者はメッセージ全体を拒否してはなりません。
Outside a Multipart/Voice-Message, conforming implementations MUST accept Text/Plain; however, specific handling is left as an implementation decision. From: [MIME2]
マルチパート/音声メッセージの外では、適合の実装はテキスト/プレーンを受け入れる必要があります。ただし、特定の処理は実装決定として残されています。From：[mime2]
Some deployed implementations based on a common interpretation of the original VPIM V2 specification reject messages with any text content rather than discard the unsupported contents. These systems will return the message to the sender with an NDN indicating lack of support for text.
元のVPIM V2仕様の一般的な解釈に基づいて、サポートされていないコンテンツを破棄するのではなく、あらゆるテキストコンテンツでメッセージを拒否しました。これらのシステムは、テキストのサポートがないことを示すNDNで送信者にメッセージを返します。
A DSN is a notification of delivery (positive DSN), non-delivery (negative DSN), or temporary delivery delay (delayed DSN). The top-level content-type of a DSN is Multipart/Report, which is defined in [REPORT]. The content-type which distinguishes DSN's from other types of notifications is Message/Delivery-Status, which is defined in [DSN].
DSNは、配信（陽性DSN）、非配信（負のDSN）、または一時的な配送遅延（DSNの遅延）の通知です。DSNのトップレベルのコンテンツタイプは、[レポート]で定義されているマルチパート/レポートです。DSNを他のタイプの通知と区別するコンテンツタイプは、[DSN]で定義されているメッセージ/配信ステータスです。
SEND RULES
ルールを送信します
A VPIM-compliant implementation MUST be able to send DSN's that conform to [REPORT] and [DSN]. Unless requested otherwise, a non-delivery DSN MUST be sent when any form of non-delivery of a message occurs.
VPIMに準拠した実装は、[レポート]および[DSN]に適合するDSNを送信できる必要があります。特に要求されていない限り、メッセージの任意の形式の非配信が発生した場合、非配信DSNを送信する必要があります。
A VPIM-compliant implementation SHOULD provide a spoken delivery status in the "human-readable" body part of the DSN, but MAY provide a textual status.
VPIMに準拠した実装は、DSNの「人間読み取り可能な」ボディ部分で音声配信ステータスを提供する必要がありますが、テキストステータスを提供する場合があります。
RECEIVE RULES
ルールを受信します
A VPIM-compliant implementation MUST be able to receive DSN's that conform to [REPORT] and [DSN].
VPIMに準拠した実装は、[レポート]および[DSN]に適合するDSNを受信できる必要があります。
A VPIM-compliant implementation MUST be able to receive a DSN whose "human-readable" body part contains a spoken delivery status phrase or a textual description. Though subsequent use of the phrase or text is a local implementation issue, the intent of the DSN MUST be presented to the end user.
VPIMに準拠した実装では、「人間が読める」ボディパーツに音声配信ステータスフレーズまたはテキストの説明が含まれているDSNを受信できる必要があります。その後のフレーズまたはテキストの使用はローカルの実装の問題ですが、DSNの意図をエンドユーザーに提示する必要があります。
An MDN is a notification indicating what happens to a message after it is deposited in the recipient's mailbox. An MDN can be positive (message was read/played/rendered/etc.) or negative (message was deleted before recipient could see it, etc.). The top-level content-type of a MDN is Multipart/Report, which is defined in [REPORT]. The content-type which distinguishes MDN's from other types of notifications is Message/Disposition-Notification, which is defined in [MDN].
MDNは、受信者のメールボックスに堆積した後にメッセージに何が起こるかを示す通知です。MDNは肯定的である可能性があります（メッセージは読み取り/再生/レンダリング/など）またはネガティブ（受信者がそれを見ることができる前にメッセージが削除されました）。MDNのトップレベルのコンテンツタイプは、[レポート]で定義されているマルチパート/レポートです。MDNを他のタイプの通知と区別するコンテンツタイプは、[MDN]で定義されているメッセージ/処分解釈です。
SEND RULES
ルールを送信します
A VPIM-compliant implementation SHOULD support the ability to request MDNs. This is done via the use of the "Disposition-Notification-To:" header field as defined in [MDN].
VPIMに準拠した実装は、MDNSを要求する機能をサポートする必要があります。これは、[MDN]で定義されている「気質 - notification to：」ヘッダーフィールドを使用して行われます。
A VPIM-compliant implementation SHOULD support the ability to send MDNs, but these MDNs MUST conform to [REPORT] and [MDN].
VPIMに準拠した実装は、MDNを送信する機能をサポートする必要がありますが、これらのMDNは[レポート]および[MDN]に準拠する必要があります。
When sending an MDN, a VPIM-compliant implementation SHOULD provide a spoken message disposition in the "human-readable" body part of the MDN, but MAY provide a textual status.
MDNを送信する場合、VPIMに準拠した実装は、MDNの「人間読み取り可能な」ボディ部分で音声メッセージの処分を提供する必要がありますが、テキストステータスを提供する場合があります。
RECEIVE RULES
ルールを受信します
A VPIM-compliant implementation SHOULD respond to an MDN request with an MDN response.
VPIMに準拠した実装は、MDN応答を使用してMDN要求に応答する必要があります。
A VPIM-compliant implementation MUST be able to receive MDNs that conform to [REPORT] and [MDN], if it is capable of requesting MDNs. If a VPIM-compliant implementation is capable of receiving MDNs, it MUST be able to receive a MDN whose "human-readable" body part contains a spoken message disposition phrase or a textual disposition description. Though subsequent use of the phrase or text is a local implementation issue, the intent of the MDN MUST be presented to the end user.
VPIMに準拠した実装は、MDNを要求できる場合、[レポート]および[MDN]に準拠するMDNを受信できる必要があります。VPIMに準拠した実装がMDNを受信できる場合、「人間の読み取り可能な」ボディパーツに音声メッセージ処分フレーズまたはテキスト処分の説明が含まれているMDNを受信できる必要があります。その後のフレーズまたはテキストの使用はローカル実装の問題ですが、MDNの意図をエンドユーザーに提示する必要があります。
VPIM v2 explicitly supports the forwarding of voice and fax content with voice or fax annotation. However, only the two constructs described below are acceptable in a VPIM message. Since only the first (i.e., Message/RFC822) can be recognized as a forwarded message (or even multiple forwarded messages), it is RECOMMENDED that this construct be used whenever possible.
VPIM V2は、音声またはFAXアノテーションを使用した音声およびFAXコンテンツの転送を明示的にサポートしています。ただし、VPIMメッセージでは、以下に説明する2つの構成要素のみが許容されます。最初の（つまり、メッセージ/RFC822）のみが転送されたメッセージ（または複数の転送されたメッセージ）として認識できるため、このコンストラクトを可能な限り使用することをお勧めします。
Forwarded VPIM messages SHOULD be sent as a Multipart/Voice-Message with the entire original message enclosed in a Message/RFC822 content-type and the annotation as a separate Audio/* or Image/* body part. If the RFC822 header fields are not available for the forwarded content, simulated header fields with available information SHOULD be constructed to indicate the original sending timestamp, and the original sender as indicated in the "From:" field. Note that at least one of "From:", "Subject:", or "Date:" MUST be present. As well, the Message/RFC822 content MUST include at least the "MIME-Version:", and "Content-Type:" header fields. From: [MIME2]
転送されたVPIMメッセージは、メッセージ/RFC822コンテンツタイプに囲まれた元のメッセージ全体を、別のオーディオ/*または画像/*ボディパーツとしてアノテーションを囲んでいるマルチパート/音声メッセージとして送信する必要があります。RFC822ヘッダーフィールドが転送されたコンテンツで使用できない場合、使用可能な情報を持つシミュレーションヘッダーフィールドを構築して、元の送信タイムスタンプと、「from」フィールドに示されている元の送信者を示す必要があります。「from：」、「 "subject："、または "date："の少なくとも1つが存在する必要があることに注意してください。同様に、メッセージ/RFC822コンテンツには、少なくとも「Mime-version：」と「content-type：」ヘッダーフィールドを含める必要があります。From：[mime2]
In the event that forwarding information is lost, the entire audio content MAY be sent as a single Audio/* segment without including any forwarding semantics. An example of this loss is an AMIS message being forwarded through an AMIS-to-VPIM gateway.
転送情報が失われた場合、オーディオコンテンツ全体が、転送セマンティクスを含めることなく、単一のオーディオ/*セグメントとして送信される場合があります。この損失の例は、AMISからVPIMへのゲートウェイを介して転送されるAMISメッセージです。
VPIM v2 explicitly supports replying to received messages.
VPIM V2は、受信したメッセージへの返信を明示的にサポートしています。
Support of multiple originator header fields in a reply message is often not possible on voice messaging systems, so it may be necessary to choose only one when gatewaying a VPIM message to another voice message system. However, implementers should note that this may make it impossible to send DSN's, MDN's, and replies to their proper destinations.
応答メッセージでの複数のオリジナルヘッダーフィールドのサポートは、音声メッセージングシステムではしばしば不可能であるため、VPIMメッセージを別の音声メッセージシステムにゲートウェイするときに1つだけを選択する必要がある場合があります。ただし、実装者は、これによりDSN、MDN、および適切な目的地に返信することが不可能になる可能性があることに注意する必要があります。
In some cases, replying to a message is not possible, such as with a message created by telephone answering (i.e., classic voice mail). In this case, the From field SHOULD contain the special address non-mail-user@domain (see 4.1.2). The recipient's VPIM system SHOULD NOT offer the option to reply to this kind of message (unless an outcalling feature is offered - which is out of scope for VPIM).
場合によっては、電話の回答（つまり、クラシックボイスメール）によって作成されたメッセージなど、メッセージへの返信は不可能です。この場合、Fromフィールドには特別なアドレスNon-Mail-User@Domainを含める必要があります（4.1.2を参照）。受信者のVPIMシステムは、この種のメッセージに返信するオプションを提供してはなりません（Autcalling機能が提供されない限り - VPIMの範囲外です）。
Messages are transported between voice mail machines using the Internet Extended Simple Mail Transfer Protocol (ESMTP). All information required for proper delivery of the message is included in the ESMTP dialog. This information, including the sender and recipient addresses, is commonly referred to as the message "envelope". This information is equivalent to the message control block in many analog voice messaging protocols.
メッセージは、インターネット拡張シンプルなメール転送プロトコル（ESMTP）を使用して、ボイスメールマシン間で輸送されます。メッセージの適切な配信に必要なすべての情報は、ESMTPダイアログに含まれています。送信者と受信者のアドレスを含むこの情報は、一般にメッセージ「封筒」と呼ばれます。この情報は、多くのアナログ音声メッセージングプロトコルのメッセージ制御ブロックと同等です。
ESMTP is a general-purpose messaging protocol, designed both to send mail and to allow terminal console messaging. Simple Mail Transport Protocol (SMTP) was originally created for the exchange of US-ASCII 7-bit text messages. Binary and 8-bit text messages have traditionally been transported by encoding the messages into a 7-bit text-like form. [ESMTP] formalized an extension mechanism for SMTP, and subsequent RFCs have defined 8-bit text networking, command streaming, binary networking, and extensions to permit the declaration of message size for the efficient transmission of large messages such as multi-minute voice mail.
ESMTPは、メールの送信とターミナルコンソールメッセージングの両方を許可するように設計された汎用メッセージプロトコルです。Simple Mail Transport Protocol（SMTP）は、もともとUS-ASCII 7ビットテキストメッセージの交換用に作成されました。バイナリと8ビットのテキストメッセージは、メッセージを7ビットのテキストのようなフォームにエンコードすることにより、伝統的に輸送されてきました。[ESMTP]はSMTPの拡張メカニズムを正式化し、その後のRFCは8ビットテキストネットワーキング、コマンドストリーミング、バイナリネットワーキング、および拡張機能を定義して、マルチミニュートボイスメールなどの大きなメッセージの効率的な伝送のメッセージサイズの宣言を許可しました。
The following sections list ESMTP commands, keywords, and parameters that are required and those that are optional for conformance to this profile.
次のセクションには、ESMTPコマンド、キーワード、および必要なパラメーターと、このプロファイルへの適合のためにオプションのパラメーターを示します。
A conforming system MUST implement all mandatory SMTP and ESMTP commands. Any defined optional command or parameter MAY be supported.
適合システムは、すべての必須SMTPおよびESMTPコマンドを実装する必要があります。定義されたオプションのコマンドまたはパラメーターはすべてサポートされる場合があります。
VPIM utilizes a number of SMTP Service Extensions to provide full-featured voice messaging service. The following extensions are profiled for use with VPIM:
VPIMは、多くのSMTPサービス拡張機能を利用して、フル機能の音声メッセージングサービスを提供しています。次の拡張機能は、VPIMで使用するためにプロファイルされています。
The DSN extension defines a mechanism which allows an SMTP client to specify (a) DSN's should be generated under certain conditions, (b) whether such DSN's should return the contents of the message, and (c) additional information, to be returned with a DSN, that allows the sender to identify both the recipient(s) for which the DSN was issued, and the transaction in which the original message was sent.
DSN拡張は、SMTPクライアントが（a）特定の条件下で生成する必要がある、（b）そのようなDSNがメッセージの内容を返すべきかどうか、（c）追加情報を、DSNは、送信者がDSNが発行された受信者と元のメッセージが送信されたトランザクションの両方を識別できるようにします。
The DSN extension MUST be supported by VPIM conforming implementations.
DSN拡張機能は、VPIMに準拠する実装によってサポートする必要があります。
In addition, beyond the requirements of [DRPT], conforming implementations MUST support NOTIFY parameter on the RCPT command to allow indication of when the originator requests a notification. The RET parameter SHOULD be supported to return the original message with the notification. Parameters ORCPT and ENVID MAY also be supported. From: [DRPT]
さらに、[DRPT]の要件を超えて、実装の適合はRCPTコマンドの通知パラメーターをサポートして、オリジネーターが通知を要求する時期を示すことを可能にする必要があります。通知とともに元のメッセージを返すために、RETパラメーターをサポートする必要があります。パラメーターORCPTおよびEnvidもサポートされる場合があります。From：[drpt]
The SIZE extension defines a mechanism whereby an SMTP client and server may interact to give the server an opportunity to decline to accept a message (perhaps temporarily) based on the client's estimate of the message size. From: [SIZE] The SIZE extension MUST be supported by VPIM-compliant implementations.
サイズ拡張機能は、SMTPクライアントとサーバーが対話して、クライアントのメッセージサイズの推定に基づいて（おそらく一時的に）メッセージを受け入れる機会をサーバーに与えるメカニズムを定義します。from：[size] size拡張機能は、VPIMに準拠した実装によってサポートする必要があります。
The ENHANCEDSTATUSCODES extension defines a mechanism whereby an SMTP server augments its responses with the enhanced mail system status codes defined in [CODES]. These codes can then be used to provide more informative explanations of error conditions. From: [STATUS]
EnhancedStatusCodes拡張は、[コード]で定義されている拡張されたメールシステムステータスコードでSMTPサーバーが応答を拡大するメカニズムを定義します。これらのコードを使用して、エラー条件のより有益な説明を提供できます。From：[ステータス]
The ENHANCEDSTATUSCODES extension SHOULD be supported by VPIM-compliant implementations.
EnhancedStatusCodes拡張は、VPIMに準拠した実装によってサポートされる必要があります。
The PIPELINING extension defines a mechanism whereby an SMTP server can indicate the extent of its ability to accept multiple commands in a single TCP send operation. Using a single TCP send operation for multiple commands can improve SMTP performance significantly. From [PIPE]
パイプライン拡張機能は、SMTPサーバーが単一のTCP送信操作で複数のコマンドを受け入れる能力の範囲を示すメカニズムを定義します。単一のTCPを使用して、複数のコマンドに対して操作を送信すると、SMTPパフォーマンスが大幅に向上する可能性があります。[パイプ]から
The PIPELINING extension SHOULD be supported by VPIM-compliant implementations.
パイプライニング拡張機能は、VPIMに準拠した実装によってサポートされる必要があります。
The CHUNKING extension defines a mechanism that enables an SMTP client and server to negotiate the use of the message data transfer command "BDAT" (in alternative to the DATA command) for efficiently sending large MIME messages. From: [BINARY]
チャンキング拡張機能は、SMTPクライアントとサーバーがメッセージデータ転送コマンド「BDAT」（データコマンドに代わる）の使用を交渉できるようにするメカニズムを定義し、大規模なMIMEメッセージを効率的に送信します。From：[バイナリ]
The CHUNKING extension MAY be supported by VPIM-compliant implementations.
チャンク拡張機能は、VPIMに準拠した実装によってサポートされる場合があります。
The BINARYMIME extension defines a mechanism that enables an SMTP client and server to negotiate the transfer of unencoded binary message data utilizing the BDAT command. From: [BINARY]
BinaryMime拡張機能は、SMTPクライアントとサーバーがBDATコマンドを使用して非エンコードされていないバイナリメッセージデータの転送を交渉できるようにするメカニズムを定義します。From：[バイナリ]
The BINARYMIME extension MAY be supported by VPIM-compliant implementations. Note that [BINARY] specifies that if BINARYMIME is to be supported, then CHUNKING has to be supported by definition.
BinaryMime拡張機能は、VPIMに準拠した実装によってサポートされる場合があります。[Binary]は、BinaryMimeがサポートされる場合、定義によりチャンクをサポートする必要があることを指定することに注意してください。
The SMTP extensions suggested or required for conformance to VPIM fall into two categories. The first category includes features that increase the efficiency of the transport system such as SIZE, BINARYMIME, and PIPELINING. In the event of a downgrade to a less-functional transport system, these features can be dropped with no functional change to the sender or recipient.
VPIMへの適合に提案または必要なSMTP拡張機能は、2つのカテゴリに分類されます。最初のカテゴリには、サイズ、バイナリマイム、パイプラインなどの輸送システムの効率を向上させる機能が含まれています。機能性の低い輸送システムに格下げされた場合、これらの機能は、送信者または受信者に機能的な変更なしで削除できます。
The second category of features is transport extensions in support of new functions. DSN and ENHANCEDSTATUSCODES provide essential improvements in the handling of delivery status notifications to bring email to the level of reliability expected of Voice Mail. To ensure a consistent level of service across an intranet or the global Internet, it is essential that VPIM-conforming ESMTP support the DSN extension at all hops between a VPIM originating system and the recipient system. In the situation where a "downgrade" is unavoidable a relay hop may be forced (by the next hop) to forward a VPIM message without the ESMTP request for delivery status notification. It is RECOMMENDED that the downgrading system should continue to attempt to deliver the message, but MUST send an appropriate delivery status notification to the originator, e.g., the message left an ESMTP host and was sent relayed to a non-DSN-aware destination, and this may be the last DSN received.
機能の2番目のカテゴリは、新しい機能をサポートする輸送拡張です。DSNおよびEnhancedStatuscodesは、配信ステータス通知の取り扱いに本質的な改善を提供し、ボイスメールに期待される信頼性のレベルに電子メールを提供します。イントラネットまたはグローバルなインターネット全体で一貫したレベルのサービスを確保するために、VPIMを構成するESMTPがVPIM発信システムとレシピエントシステム間のすべてのホップでDSN拡張をサポートすることが不可欠です。「ダウングレード」が避けられない状況では、リレーホップが（次のホップにより）配信ステータス通知のESMTPリクエストなしでVPIMメッセージを転送することを余儀なくされる場合があります。格下げシステムは引き続きメッセージを配信しようとする必要がありますが、適切な配信ステータス通知をオリジネーターに送信する必要があります。これは、最後に受け取ったDSNかもしれません。
It is the responsibility of a VPIM system to provide the fully-qualified domain name (FQDN) of the recipient based on the address entered by the user (if the entered address is not already a FQDN). This would typically be an issue on systems that offer only a telephone user interface. The mapping of the dialed target number to a routable FQDN address, allowing delivery to the destination system, can be accomplished through implementation-specific means.
ユーザーが入力したアドレスに基づいて、受信者の完全に資格のあるドメイン名（FQDN）を提供することは、VPIMシステムの責任です（入力されたアドレスがまだFQDNではない場合）。これは通常、電話ユーザーインターフェイスのみを提供するシステムの問題になります。宛先システムへの配信を可能にするルーティング可能なFQDNアドレスへのダイヤルターゲット番号のマッピングは、実装固有の手段を通じて実現できます。
To facilitate a local cache, an implementation may wish to populate local directories with the first and last names, as well as the senders' spoken name information extracted from received messages. Addresses or names parsed from the header fields of VPIM messages MAY be used to populate directories.
ローカルキャッシュを容易にするために、実装は、受信したメッセージから抽出された送信者の話された名前情報だけでなく、最初の名前と姓にローカルディレクトリに登録することをお勧めします。VPIMメッセージのヘッダーフィールドから解析されたアドレスまたは名前を使用して、ディレクトリの設定を使用できます。
The Internet protocols provide a mechanism for the management of messaging systems, from the management of the physical network through the management of the message queues. SNMP SHOULD be supported on a VPIM-conforming machine.
インターネットプロトコルは、物理ネットワークの管理からメッセージキューの管理を通じて、メッセージングシステムの管理のメカニズムを提供します。SNMPは、VPIM構成マシンでサポートする必要があります。
The digital interface to the VM and the TCP/IP protocols MAY be managed. MIB II MAY be implemented to provide basic statistics and reporting of TCP and IP protocol performance [MIB II].
VMとTCP/IPプロトコルへのデジタルインターフェイスを管理できます。MIB IIは、TCPおよびIPプロトコルのパフォーマンスの基本統計と報告を提供するために実装される場合があります[MIB II]。
VPIM is a messaging application that will be supported in several environments and be supported on differing devices. These environments include traditional voice processing systems, desktop voice messaging systems, store-and-forward relays, and protocol translation gateways.
VPIMは、いくつかの環境でサポートされ、異なるデバイスでサポートされるメッセージングアプリケーションです。これらの環境には、従来の音声処理システム、デスクトップ音声メッセージングシステム、ストアアンドフォワードリレー、プロトコル翻訳ゲートウェイが含まれます。
In order to accommodate all environments, this document defines two areas of conformance: transport and content.
すべての環境に対応するために、このドキュメントでは、輸送とコンテンツという2つの適合領域を定義します。
Transport-conformant systems will pass VPIM messages in a store-and-forward manner with assured delivery notifications and without the loss of information. It is expected that most store-and-forward Internet mail-based messaging systems will be VPIM transport-conformant.
トランスポートコンバントシステムは、保証された配信通知とともに、情報を失うことなく、ストアとフォワードの方法でVPIMメッセージを渡します。ほとんどのストアアンドフォワードインターネットメールベースのメッセージングシステムは、VPIM Transport Conformantになることが期待されています。
Content-conformant systems will generate and interpret VPIM messages. Conformance in the generation of VPIM messages indicates that the restrictions of this profile are honored. Only contents specified in this profile or extensions agreed to by bilateral agreement may be sent. Conformance in the interpretation of VPIM messages indicates that all VPIM content types and constructs can be received; that all mandatory VPIM content types can be decoded and presented to the recipient in an appropriate manner; and that any unrenderable contents result in the appropriate notification.
Content-Conformant Systemsは、VPIMメッセージを生成および解釈します。VPIMメッセージの生成の適合は、このプロファイルの制限が尊重されていることを示しています。このプロファイルまたは二国間契約によって合意された拡張で指定された内容のみを送信できます。VPIMメッセージの解釈における適合は、すべてのVPIMコンテンツタイプとコンストラクトを受信できることを示しています。すべての必須のVPIMコンテンツタイプは、適切な方法でレシピエントにデコードして提示できること。そして、無知な内容が適切な通知をもたらすこと。
A summary of the conformance requirements is contained in Appendix A.
適合要件の概要は、付録Aに含まれています。
VPIM end systems are expected to be both transport- and content-conformant. Voice messaging systems and protocol conversion gateways are considered end systems.
VPIM ENDシステムは、輸送とコンテンツの両方の構成剤であると予想されます。音声メッセージングシステムとプロトコル変換ゲートウェイは、エンドシステムと見なされます。
Relay systems are expected to be transport-conformant in order to receive and send conforming messages. However, they must also create VPIM-conforming delivery status notifications in the event of delivery problems.
リレーシステムは、適合メッセージを受信して送信するために輸送コンバース剤であると予想されます。ただし、配信の問題が発生した場合、VPIMを構成する配信ステータス通知を作成する必要があります。
Desktop Email clients that support VPIM are expected to be content-conformant. Desktop email clients use various protocols and API's for exchanging messages with the local message store and message transport system. While these clients may benefit from VPIM transport capabilities, specific client-server requirements are out-of-scope for this document.
VPIMをサポートするデスクトップ電子メールクライアントは、コンテンツコンフォーマントであると予想されます。デスクトップメールクライアントは、ローカルメッセージストアおよびメッセージトランスポートシステムとメッセージを交換するために、さまざまなプロトコルとAPIを使用します。これらのクライアントはVPIM輸送機能の恩恵を受ける可能性がありますが、このドキュメントの特定のクライアントサーバー要件はスコープ外です。
This document is a profile of existing Internet mail protocols. To maintain interoperability with Internet mail, any security to be provided should be part of the Internet security infrastructure, rather than a new mechanism or some other mechanism outside of the Internet infrastructure.
このドキュメントは、既存のインターネットメールプロトコルのプロファイルです。インターネットメールでの相互運用性を維持するには、提供されるセキュリティを提供するすべてのセキュリティは、インターネットインフラストラクチャ以外の新しいメカニズムやその他のメカニズムではなく、インターネットセキュリティインフラストラクチャの一部である必要があります。
Both Internet mail and voice messaging have their own set of threats and countermeasures. As such, this specification does not create any security issues not already existing in the profiled Internet mail and voice mail protocols themselves. This section attends only to the set of additional threats that ensue from integrating the two services.
インターネットメールと音声メッセージの両方に、独自の脅威と対策セットがあります。そのため、この仕様では、プロファイルされたインターネットメールおよびボイスメールプロトコル自体にまだ存在していないセキュリティの問題を作成するものではありません。このセクションでは、2つのサービスを統合することで生じる追加の脅威のセットにのみ対応します。
The actual sender of the voice message might not be the same as that specified in the "Sender:" or "From:" message header fields or the MAIL FROM address from the SMTP envelope. In a tightly constrained environment, sufficient physical and software controls may be able to ensure prevention of this problem. In addition, the recognition of the sender's voice may provide confidence of the sender's identity irrespective of that specified in "Sender:" or "From:". It should be recognized that SMTP implementations do not provide inherent authentication of the senders of messages, nor are sites under obligation to provide such authentication.
音声メッセージの実際の送信者は、「送信者」または「from：」で指定されているものと同じではない場合があります。メッセージヘッダーフィールドまたはSMTPエンベロープからのアドレスからのメール。厳密に制約された環境では、十分な物理的およびソフトウェア制御がこの問題の防止を確保できる可能性があります。さらに、送信者の声の認識は、「送信者：」または「from：」で指定されたものに関係なく、送信者のアイデンティティの信頼を提供する可能性があります。SMTP実装は、メッセージの送信者の固有の認証を提供しないことも、そのような認証を提供する義務も与えられていないことを認識する必要があります。
Assigning an Internet mail address to a voice mailbox opens the possibility of receiving unsolicited messages (either text or voice mail). Traditionally, voice mail systems operated in closed environments and were not susceptible to unknown senders. Voice mail users have a higher expectation of mailbox privacy and may consider such messages as a security breach. Many Internet mail systems are choosing to block all messages from unknown sources in an attempt to curb this problem.
インターネットメールアドレスをボイスメールボックスに割り当てると、未承諾メッセージ（テキストまたはボイスメールのいずれか）を受信する可能性があります。従来、ボイスメールシステムは閉じた環境で動作し、未知の送信者の影響を受けませんでした。ボイスメールユーザーは、メールボックスのプライバシーを期待しており、セキュリティ侵害などのメッセージを検討する場合があります。多くのインターネットメールシステムは、この問題を抑制するために、未知のソースからのすべてのメッセージをブロックすることを選択しています。
Users of voice messaging systems have an expectation of a level of message privacy that is higher than the level provided by Internet mail without security enhancements. This expectation of privacy by users SHOULD be preserved as much as possible.
音声メッセージングシステムのユーザーは、セキュリティの強化なしでインターネットメールが提供するレベルよりも高いレベルのメッセージプライバシーを期待しています。ユーザーによるプライバシーのこの期待は、可能な限り保存する必要があります。
Sufficient physical and software control may be acceptable in constrained environments. Further, the profile specified in this document does not in any way preclude the use of any Internet object or channel security protocol to encrypt, authenticate, or non-repudiate the messages.
制約された環境では、十分な物理的およびソフトウェア制御が受け入れられる場合があります。さらに、このドキュメントで指定されているプロファイルは、メッセージを暗号化、認証、または非回復するためのインターネットオブジェクトまたはチャネルセキュリティプロトコルの使用を決して排除しません。
[8BIT] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D. Crocker, "SMTP Service Extension for 8bit-MIMEtransport", RFC 1652, July 1994.
[8bit] Klensin、J.、Freed、N.、Rose、M.、Stefferud、E。、およびD. Crocker、「8bit-MimetransportのSMTPサービス拡張」、RFC 1652、1994年7月。
[ADPCM] Vaudreuil, G. and G. Parsons, "Toll Quality Voice - 32 kbit/s Adaptive Differential Pulse Code Modulation (ADPCM) MIME Sub-type Registration", RFC 3802, June 2004.
[ADPCM] Vaudreuil、G。およびG. Parsons、「Toll Quality Voice -32 kbit/s適応微分パルスコード変調（ADPCM）MIMEサブタイプ登録」、2004年6月、RFC 3802。
[AMIS-A] Audio Messaging Interchange Specifications (AMIS) - Analog Protocol Version 1, Issue 2, February 1992.
[AMIS -A]オーディオメッセージングインターチェンジ仕様（AMIS） - アナログプロトコルバージョン1、第2号、1992年2月。
[AMIS-D] Audio Messaging Interchange Specifications (AMIS) - Digital Protocol Version 1, Issue 3, August 1993.
[AMIS -D]オーディオメッセージングインターチェンジ仕様（AMIS） - デジタルプロトコルバージョン1、第3号、1993年8月。
[BINARY] Vaudreuil, G., "SMTP Service Extensions for Transmission of Large and Binary MIME Messages", RFC 3030, December 2000.
[Binary] Vaudreuil、G。、「大型およびバイナリMIMEメッセージの送信用SMTPサービス拡張式」、RFC 3030、2000年12月。
[CODES] Vaudreuil, G. "Enhanced Mail System Status Codes", RFC 1893, January 1996.
[コード] Vaudreuil、G。「拡張されたメールシステムステータスコード」、RFC 1893、1996年1月。
[MIMEDIR] Dawson, F., Howes, T. and M. Smith, "A MIME Content-Type for Directory Information", RFC 2425, September 1998.
[Mimedir] Dawson、F.、Howes、T。and M. Smith、「ディレクトリ情報のMIMEコンテンツタイプ」、RFC 2425、1998年9月。
[DISP] Troost, R. and S. Dorner, "Communicating Presentation Information in Internet Messages: The Content-Disposition Header", RFC 2183, August 1997.
[Disp] Troost、R。およびS. Dorner、「インターネットメッセージのプレゼンテーション情報の伝達：コンテンツ拡散ヘッダー」、RFC 2183、1997年8月。
[DNS1] Mockapetris, P., "Domain names - implementation and specification", RFC 1035, November 1987.
[DNS1] Mockapetris、P。、「ドメイン名 - 実装と仕様」、RFC 1035、1987年11月。
[DNS2] Mockapetris, P., "Domain names - concepts and facilities", RFC 1034, November 1987.
[DNS2] Mockapetris、P。、「ドメイン名 - 概念と施設」、RFC 1034、1987年11月。
[DRPT] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", RFC 3461, January 2003.
[DRPT] MOORE、K。、「配信ステータス通知（DSNS）のSimple Mail Transfer Protocol（SMTP）サービス拡張」、RFC 3461、2003年1月。
[DSN] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, January 2003.
[DSN] Moore、K。およびG. Vaudreuil、「配信ステータス通知の拡張可能なメッセージ形式」、RFC 3464、2003年1月。
[DUR] Parsons, G. and G. Vaudreuil, "Content Duration MIME Header Definition", RFC 3803, June 2004.
[DUR] Parsons、G。およびG. Vaudreuil、「コンテンツ期間MIMEヘッダー定義」、RFC 3803、2004年6月。
[E164] CCITT Recommendation E.164 (1991), Telephone Network and ISDN Operation, Numbering, Routing and Mobile Service - Numbering Plan for the ISDN Era.
[E164] CCITTの推奨事項E.164（1991）、電話ネットワークおよびISDN操作、番号付け、ルーティングとモバイルサービス - ISDN時代の番号付け計画。
[ESMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[ESMTP] Klensin、J。、「Simple Mail Transfer Protocol」、RFC 2821、2001年4月。
[G726] CCITT Recommendation G.726 (1990), General Aspects of Digital Transmission Systems, Terminal Equipment - 40, 32, 24,16 kbit/s Adaptive Differential Pulse Code Modulation (ADPCM).
[G726] CCITTの推奨G.726（1990）、デジタル伝送システムの一般的な側面、ターミナル機器-40、32、24,16 Kbit/s適応型差動パルスコード変調（ADPCM）。
[HOSTREQ] Braden, R., "Requirements for Internet Hosts -- Application and Support", STD 3, RFC 1123, October 1989.
[Hostreq] Braden、R。、「インターネットホストの要件 - アプリケーションとサポート」、STD 3、RFC 1123、1989年10月。
[LANG] Alvestrand, H., "Tags for the Identification of Languages", BCP 47, RFC 3066, January 2001.
[Lang] Alvestrand、H。、「言語の識別のためのタグ」、BCP 47、RFC 3066、2001年1月。
[MDN] Hansen, T., Ed. and G. Vaudreuil, Ed., "Message Disposition Notification", RFC 3798, May 2004.
[MDN] Hansen、T.、ed。およびG. Vaudreuil編、「メッセージ処分通知」、RFC 3798、2004年5月。
[MIB II] Rose, M., "Management Information Base for Network Management of TCP/IP-based internets: MIB-II", RFC 1213, March 1991.
[MIB II] Rose、M。、「TCP/IPベースのインターネットのネットワーク管理のための管理情報ベース：MIB-II」、RFC 1213、1991年3月。
[MIME1] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[Mime1] Freed、N。and N. Borenstein、「多目的インターネットメール拡張機能（MIME）パート1：インターネットメッセージボディの形式」、RFC 2045、1996年11月。
[MIME2] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types ", RFC 2046, November 1996.
[Mime2] Freed、N。およびN. Borenstein、「多目的インターネットメールエクステンション（MIME）パート2：メディアタイプ」、RFC 2046、1996年11月。
[MIME3] Moore, K., "Multipurpose Internet Mail Extensions (MIME) Part Three: Message Header Extensions for Non-ASCII Text ", RFC 2047, November 1996.
[Mime3] Moore、K。、「多目的インターネットメール拡張機能（MIME）パート3：ASSASCII以外のテキスト用のメッセージヘッダー拡張機能」、RFC 2047、1996年11月。
[MIME4] Freed, N., Klensin, J. and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", RFC 2048, November 1996.
[Mime4] Freed、N.、Klensin、J。およびJ. Postel、「多目的インターネットメール拡張機能（MIME）パート4：登録手順」、RFC 2048、1996年11月。
[MIME5] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples ", RFC 2049, November 1996.
[Mime5] Freed、N。and N. Borenstein、「多目的インターネットメール拡張機能（MIME）パート5：適合基準と例」、RFC 2049、1996年11月。
[PIPE] Freed, N.and A. Cargille, "SMTP Service Extension for Command Pipelining" STD 60, RFC 2920, September 2000.
[Pipe] Freed、N.and A. Cargille、 "Command Pipelinging for Command Pipelining" Std 60、RFC 2920、2000年9月。
[REPORT] Vaudreuil, G., "The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages", RFC 3462, January 2003.
[レポート] Vaudreuil、G。、「メールシステム管理メッセージのレポートのマルチパート/レポートコンテンツタイプ」、RFC 3462、2003年1月。
[REQ] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[Req] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC822] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, August 1982.
[RFC822] Crocker、D。、「ARPAインターネットテキストメッセージの形式の標準」、STD 11、RFC 822、1982年8月。
[SIZE] Klensin, J., Freed, N. and K. Moore, "SMTP Service Extensions for Message Size Declaration" STD 10, RFC 1870, November 1995.
[サイズ] Klensin、J.、Freed、N。およびK. Moore、「メッセージサイズ宣言のSMTPサービス拡張」STD 10、RFC 1870、1995年11月。
[STATUS] Freed, N., "SMTP Service Extension for Returning Enhanced Error Codes", RFC 2034, October 1996.
[Status] Freed、N。、「強化されたエラーコードを返すためのSMTPサービス拡張」、RFC 2034、1996年10月。
[TIFF-F] Parsons, G. and J. Rafferty, "Tag Image File Format: Application F", RFC 2306, March 1998.
[Tiff-F] Parsons、G。およびJ. Rafferty、「タグイメージファイル形式：アプリケーションF」、RFC 2306、1998年3月。
[TIFFREG] Parsons, G., Rafferty, J. and S. Zilles, "Tag Image File Format: image/tiff - MIME sub-type registration", RFC 2302, March 1998.
[Tiffreg] Parsons、G.、Rafferty、J。and S. Zilles、「タグイメージファイル形式：Image/Tiff -Mimeサブタイプ登録」、RFC 2302、1998年3月。
[V-MSG] Vaudreuil, G. and G. Parsons, "VPIM Voice Message MIME Sub-type Registration", RFC 2423, September 1998.
[V-MSG] Vaudreuil、G。およびG. Parsons、「VPIM Voice Message Mimeサブタイプ登録」、RFC 2423、1998年9月。
[VCARD] Dawson, F. and T. Howes, "vCard MIME Directory Profile" RFC 2426, September 1998.
[Vcard] Dawson、F。and T. Howes、 "Vcard Mime Dime Directory Profile" RFC 2426、1998年9月。
[VPIM1] Vaudreuil, G., "Voice Profile for Internet Mail", RFC 1911, February 1996.
[VPIM1] Vaudreuil、G。、「インターネットメールの音声プロファイル」、RFC 1911、1996年2月。
[VPIM2] Vaudreuil, G. and G. Parsons, "Voice Profile for Internet Mail, Version 2", RFC 2421, September 1998.
[VPIM2] Vaudreuil、G。およびG. Parsons、「インターネットメールの音声プロファイル、バージョン2」、RFC 2421、1998年9月。
[X.400] CCITT/ISO, "CCITT Recommendations X.400/ ISO/IEC 10021-1, Message Handling: System and Service Overview", December 1988.
[X.400] CCITT/ISO、「CCITT推奨X.400/ISO/IEC 10021-1、メッセージ処理：システムとサービスの概要」、1988年12月。
The authors would like to offer a special thanks to the Electronic Messaging Association (EMA), especially the members of the Voice Messaging Committee, and the IETF VPIM Work Group, for their support of the VPIM specification and the efforts they have made to ensure its success.
著者は、VPIM仕様の支援とその努力を確実にするために行った努力について、電子メッセージング協会（EMA）、特にIETF VPIMワークグループのメンバーに特別な感謝を提供したいと考えています。成功。
The following table summarizes the profile of VPIM version 2 detailed in this document. Since in many cases it is not possible to simplify the qualifications for supporting each feature this appendix is informative. The reader is recommended to read the complete explanation of each feature in the referenced section. The text in the previous sections shall be deemed authoritative if any item in this table is ambiguous.
次の表は、このドキュメントで詳述されているVPIMバージョン2のプロファイルをまとめたものです。多くの場合、各機能をサポートする資格を簡素化することはできないため、この付録は有益です。読者は、参照セクションの各機能の完全な説明を読むことをお勧めします。前のセクションのテキストは、このテーブルの項目があいまいである場合、権威あるとみなされます。
The conformance table is separated into various columns:
適合テーブルはさまざまな列に分けられます。
Feature - name of protocol feature (note that the indenting indicates a hierarchy of conformance, i.e., the conformance of a lower feature is only relevant if there is conformance to the higher feature)
機能 - プロトコル機能の名前（インデントは適合性の階層を示していることに注意してください。つまり、より高い機能に適合している場合にのみ関連するものです）
Section - reference section in main text of this document
セクション - このドキュメントのメインテキストの参照セクション
Area - conformance area to which each feature applies: C - content T - transport
エリア - 各機能が適用される適合エリア：C-コンテンツT-トランスポート
Status - whether the feature is mandatory, optional, or prohibited. The key words used in this table are to be interpreted as described in [REQ], though the following list gives a quick overview of the different degrees of feature conformance:
ステータス - 機能が必須、オプション、または禁止されているかどうか。この表で使用されるキーワードは、[Req]で説明されているように解釈されますが、次のリストは、特徴の適合性の異なる程度の概要を簡単に示しています。
Must - mandatory Should - required in the absence of a compelling need to omit. May - optional Should not - prohibited in the absence of a compelling need. Must not - prohibited
必須 - 必須 - 省略する必要性がない場合に必要です。5月 - オプションは、説得力のあるニーズがない場合に禁止されてはいけません。してはいけません - 禁止されています
Footnote - special comment about conformance for a particular feature
脚注 - 特定の機能への適合性に関する特別なコメント
VPIM version 2 Conformance
| | | | |S| |
| | | | | |H| |F
| | | | | |O|M|o
| | | |S| |U|U|o
| | | |H| |L|S|t
| |A|M|O| |D|T|n
| |R|U|U|M| | |o
| |E|S|L|A|N|N|t
| |A|T|D|Y|O|O|t
FEATURE |SECTION | | | | |T|T|e
-------------------------------------------|----------|-|-|-|-|-|-|-
| | | | | | | |
Message Addressing Formats: | | | | | | | |
Use DNS host names |4.1 |C|x| | | | |
Use only numbers in mailbox IDs |4.1.1 |C| |x| | | |
Numbers in mailbox IDs follow E.164 |4.1.1 |C| |x| | | |
Use alpha-numeric mailbox IDs |4.1.1 |C| | |x| | |
Support of postmaster@domain |4.1.2 |C|x| | | | |
Support of non-mail-user@domain |4.1.2 |C| |x| | | |
Support of distribution lists |4.1.3 |C| | |x| | |
| | | | | | | |
Message Header Fields: | | | | | | | |
Sending outbound messages | | | | | | | |
From |4.2.1 |C|x| | | | |
Addition of text name |4.2.1 |C| |x| | | |
Same value as MAIL FROM |4.2.1 |C| |x| | | |
To |4.2.2 |C| |x| | | |1
cc |4.2.3 |C| | |x| | |1
Date |4.2.4 |C|x| | | | |
Sender |4.2.5 |C| | |x| | |
Return-Path |4.2.6 |C| | | | |x|
Message-ID |4.2.7 |C|x| | | | |
Reply-To |4.2.8 |C| | | |x| |
Received |4.2.9 |C|x| | | | |
MIME Version: 1.0 (Voice 2.0) |4.2.10 |C| |x| | | |
Content-Type |4.2.11 |C|x| | | | |
Content-Transfer-Encoding |4.2.12 |C|x| | | | |
Sensitivity |4.2.13 |C| | |x| | |
Importance |4.2.14 |C| | |x| | |
Subject |4.2.15 |C| |x| | | |
Disposition-notification-to |4.7 |C| |x| | | |
Other Headers |4.2 |C| | |x| | |
| | | | | | | |
| | | | | |H| |F
| | | | | |O|M|o
| | | |S| |U|U|o
| | | |H| |L|S|t
| |A|M|O| |D|T|n
| |R|U|U|M| | |o
| |E|S|L|A|N|N|t
| |A|T|D|Y|O|O|t
FEATURE |SECTION | | | | |T|T|e
-------------------------------------------|----------|-|-|-|-|-|-|-
Receiving inbound messages | | | | | | | |
From |4.2.1 |C|x| | | | |
Present text personal name |4.2.1 |C| | |x| | |
To |4.2.2 |C|x| | | | |
cc |4.2.3 |C| | |x| | |
Date |4.2.4 |C|x| | | | |
Conversion of Date to local time |4.2.4 |C| |x| | | |
Sender |4.2.5 |C| | |x| | |
Return-Path |4.2.6 |C| |x| | | |
Message-ID |4.2.7 |C| | |x| | |
MDN requested |4.2.7 |C|x| | | | |
Reply-To |4.2.8 |C| | |x| | |
Received |4.2.9 |C| | |x| | |
MIME Version: 1.0 (Voice 2.0) |4.2.10 |C| |x| | | |
Content Type |4.2.11 |C|x| | | | |
Content-Transfer-Encoding |4.2.12 |C|x| | | | |
Sensitivity |4.2.13 |C|x| | | | |2
Importance |4.2.14 |C| | |x| | |
Subject |4.2.15 |C| | |x| | |
Disposition-notification-to |4.7 |C| |x| | | |
Other Headers |4.2 |C|x| | | | |3
| | | | | | | |
Message Content Encoding: | | | | | | | |
Sending outbound audio/fax contents | | | | | | | |
7BIT |4.2.12 |C| | | | |x|
8BIT |4.2.12 |C| | | | |x|
Quoted Printable |4.2.12 |C| | | | |x|
Base64 |4.2.12 |C|x| | | | |4
Binary |4.2.12 |C| |x| | | |5
Receiving inbound message contents | | | | | | | |
7BIT |4.2.12 |C|x| | | | |
8BIT |4.2.12 |C|x| | | | |
Quoted Printable |4.2.12 |C|x| | | | |
Base64 |4.2.12 |C|x| | | | |
Binary |4.2.12 |C|x| | | | |5
| | | | | | | |
| | | | |S| |
| | | | | |H| |F
| | | | | |O|M|o
| | | |S| |U|U|o
| | | |H| |L|S|t
| |A|M|O| |D|T|n
| |R|U|U|M| | |o
| |E|S|L|A|N|N|t
| |A|T|D|Y|O|O|t
FEATURE |SECTION | | | | |T|T|e
-------------------------------------------|----------|-|-|-|-|-|-|-
Message Content Types: | | | | | | | |
Sending outbound messages | | | | | | | |
Multipart/Voice-Message |4.4.1 |C|x| | | | |
Message/RFC822 |4.4.2 |C| |x| | | |
Audio/32KADPCM |4.4.3 |C|x| | | | |
Content-Description |4.3.1 |C| | |x| | |
Content-Disposition |4.3.2 |C|x| | | | |
Content-Duration |4.3.3 |C| | |x| | |
Content-Language |4.3.4 |C| | |x| | |
Image/TIFF; application=faxbw |4.4.4 |C|x| | | | |7
Text/Directory |4.5.2 |C| | | |x| |9
Text/plain |4.5.4 |C| | | |x| |
Audio/* or Image/* (other encodings) |4.5.3 |C| | | |x| |
Other contents |4.5 |C| | | | |x|
Multipart/Mixed |4.5.1 |C| | |x| | |
Text/plain |4.5.4 |C| | |x| | |
Multipart/Report |4.6, 4.7 |C|x| | | | |
human-readable part is voice |4.6, 4.7 |C| |x| | | |
human-readable part is text |4.6, 4.7 |C| | |x| | |
Message/Delivery-Status |4.6 |C|x| | | | |
Message/Disposition-Notification |4.7 |C| |x| | | |
Other contents |4.5 |C| | | |x| |6
Receiving in inbound messages | | | | | | | |
Multipart/Voice-Message |4.4.1 |C|x| | | | |
Message/RFC822 |4.4.2 |C|x| | | | |
Audio/32KADPCM |4.4.3 |C|x| | | | |
Content-Description |4.3.1 |C| | |x| | |
Content-Disposition |4.3.2 |C| |x| | | |
Content-Duration |4.3.3 |C| | |x| | |
Content-Language |4.3.4 |C| | |x| | |
Image/TIFF; application=faxbw |4.4.4 |C| |x| | | |8
Text/Directory |4.5.2 |C|x| | | | |9
Text/plain |4.5.4 |C| | |x| | |
Audio/* or Image/* (other encodings) |4.5.3 |C| | |x| | |
Other contents |4.5 |C| | |x| | |
Multipart/Mixed |4.5.1 |C| | |x| | |
| | | | | |S| |
| | | | | |H| |F
| | | | | |O|M|o
| | | |S| |U|U|o
| | | |H| |L|S|t
| |A|M|O| |D|T|n
| |R|U|U|M| | |o
| |E|S|L|A|N|N|t
| |A|T|D|Y|O|O|t
FEATURE |SECTION | | | | |T|T|e
------------------------------------------|-----------|-|-|-|-|-|-|-
| | | | | | | |
Text/plain |4.5.4 |C|x| | | | |
Multipart/Report |4.6, 4.7 |C|x| | | | |
human-readable part is voice |4.6, 4.7 |C|x| | | | |
human-readable part is text |4.6, 4.7 |C|x| | | | |
Message/Delivery-Status |4.6 |C|x| | | | |
Message/Disposition-Notification |4.7 |C| |x| | | |
Other contents |4.5 |C| | |x| | |6
| | | | | | | |
Forwarded Messages | | | | | | | |
use Message/RFC822 construct |4.8 |C| |x| | | |
simulate headers if none available |4.8 |C| |x| | | |
| | | | | | | |
Reply Messages |4.9 |C|x| | | | |
send to Reply-To, else From address |4.2.8 |C| | |x| | |
send to non-mail-user |4.9 |C| | | |x| |
| | | | | | | |
Notifications | | | | | | | |
use Multipart/Report format |4.6, 4.7 |C|x| | | | |
always send error on non-delivery |4.6 |C|x| | | | |
send error messages to return-path |4.2.6 |C|x| | | | |
| | | | | | | |
Message Transport Protocol: | | | | | | | |
Base ESMTP Commands | | | | | | | |
HELO |5.1 |T|x| | | | |
MAIL FROM |5.1 |T|x| | | | |
RCPT TO |5.1 |T|x| | | | |
DATA |5.1 |T|x| | | | |
TURN |5.1 |T| | | | |x|
QUIT |5.1 |T|x| | | | |
RSET |5.1 |T|x| | | | |
VRFY |5.1 |T| | |x| | |
EHLO |5.1 |T|x| | | | |
BDAT |5.1 |T| | |x| | |5
| | | | |S| |
| | | | | |H| |F
| | | | | |O|M|o
| | | |S| |U|U|o
| | | |H| |L|S|t
| |A|M|O| |D|T|n
| |R|U|U|M| | |o
| |E|S|L|A|N|N|t
| |A|T|D|Y|O|O|t
FEATURE |SECTION | | | | |T|T|e
-------------------------------------------|----------|-|-|-|-|-|-|-
| | | | | | | |
ESMTP Keywords & Parameters | | | | | | | |
DSN |5.2.1 |T|x| | | | |
NOTIFY |5.2.1 |T|x| | | | |
RET |5.2.1 |T| |x| | | |
ENVID |5.2.1 |T| | |x| | |
ORCPT |5.2.1 |T| | |x| | |
SIZE |5.2.2 |T|x| | | | |
ENHANCEDSTATUSCODES |5.2.3 |T| |x| | | |
PIPELINING |5.2.4 |T| |x| | | |
CHUNKING |5.2.5 |T| | |x| | |
BINARYMIME |5.2.6 |T| | |x| | |
| | | | | | | |
ESMTP-SMTP Downgrading | | | | | | | |
send delivery report upon downgrade |5.3 |T|x| | | | |
| | | | | | | |
Directory Address Resolution | | | | | | | |
provide facility to resolve addresses |6 |C| |x| | | |
use headers to populate local directory |6 |C| | |x| | |
| | | | | | | |
Management Protocols: | | | | | | | |
Network management |7.1 |T| | |x| | |
-------------------------------------------|----------|-|-|-|-|-|-|-
Footnotes:
脚注：
1. SHOULD leave blank if all recipients are not known or resolvable. 2. If a sensitive message is received by a system that does not support sensitivity, then it MUST be returned to the originator with an appropriate error notification. Also, a received sensitive message MUST NOT be forwarded to anyone. 3. If the additional header fields are not understood they MAY be ignored. 4. When binary transport is not available. 5. When binary transport is available.
1. すべての受信者が不明または解決できない場合は、空白のままにする必要があります。2.感度をサポートしないシステムによって機密メッセージが受信される場合、適切なエラー通知でオリジネーターに返す必要があります。また、受信した敏感なメッセージを誰にでも転送してはなりません。3.追加のヘッダーフィールドが理解されていない場合、それらは無視される可能性があります。4.バイナリ輸送が利用できない場合。5.バイナリトランスポートが利用可能な場合。
6. Other un-profiled contents MUST only be sent by bilateral agreement. 7. If fax is supported. 8. If the fax content cannot be presented it MAY be dropped. 9. Handling of a vCard in text/directory is no longer defined.
6. 他の植物能力のないコンテンツは、二国間協定によってのみ送信する必要があります。7. FAXがサポートされている場合。8. FAXコンテンツを提示できない場合は、削除される場合があります。9.テキスト/ディレクトリでのVカードの処理は、もはや定義されていません。
The following message is a full-featured message addressed to two recipients. The message includes the sender's spoken name, spoken subject and a short speech segment. The message is marked as important and private.
次のメッセージは、2人の受信者にアドレス指定されたフル機能のメッセージです。メッセージには、送信者の音声名、話し言葉、短い音声セグメントが含まれています。メッセージは重要かつプライベートとしてマークされています。
To: +19725551212@vm1.mycompany.com
To: +16135551234@VM1.mycompany.com
From: "Parsons, Glenn" <12145551234@VM2.mycompany.com>
Date: Mon, 26 Aug 93 10:20:20 -0700 (CDT)
MIME-Version: 1.0 (Voice 2.0)
Content-type: Multipart/Voice-Message; Version=2.0;
Boundary="MessageBoundary"
Content-Transfer-Encoding: 7bit
Message-ID: 123456789@VM2.mycompany.com
Sensitivity: Private
Importance: High
--MessageBoundary
Content-type: Audio/32KADPCM
Content-Transfer-Encoding: Base64
Content-Disposition: inline; voice=Originator-Spoken-Name
Content-Language: en-US
Content-ID: part1@VM2-4321
glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd (This is a sample of the base-64 Spoken Name data) fgdhgddlkgpokpeowrit09==
glslfdslsertiflktfpgktportrpktpfgtpoitpdasssdasddasdasd（これはbase-64 aceand name dataのサンプルです）fgdhgdddlkgpokpeowrit09 =====
--MessageBoundary
Content-type: Audio/32KADPCM
Content-Transfer-Encoding: Base64
Content-Disposition: inline; voice=Spoken-Subject
Content-Language: en-US
Content-ID: part2@VM2-4321
glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd (This is a sample of the base-64 Spoken Subject data) fgdhgddlkgpokpeowrit09==
glslfdslsertiflktfpgktportrpktpfgtpoitpdasssdasddasdasd（これはBase-64の音声主題データのサンプルです）fgdhgdddlkgpokpeowrit09 =====
--MessageBoundary
Content-type: Audio/32KADPCM
Content-Transfer-Encoding: Base64
Content-Description: Brand X Voice Message
Content-Disposition: inline; voice=Voice-Message; filename=msg1.726
Content-Duration: 25
iIiIiIjMzN3czdze3s7d7fwfHhcvESJVe/4yEhLz8/FOQjVFRERCESL/zqrq (This is a sample of the base64 message data) zb8tFdLTQt1PXj u7wjOyRhws+krdns7Rju0t4tLF7cE0K0MxOTOnRW/Pn30c8uHi9==
iiiiijmzn3czdze3s7d7fwfhhcvesjve/4yehlz8/foqjvfrercesl/zqrq（これはbase64メッセージデータのサンプルです）zb8tfdltqt1pxj u8wjoyrhhws krdns7rju0t4t4tplff7cotp8mxtp80mxtp80mxtp800mxp80mxtp800mxp800mxt4t4t4t4t4t4t4t4t4t4t4t4t4t4t4t4t4t4t4t4t4t4t4t4t4t4t4t4t4t4t4t4t4t4t4t4t4tplff7 ==
--MessageBoundary- - - -
The following message is a forwarded single segment voice. Both the forwarded message and the forwarding message contain the senders spoken names.
次のメッセージは、転送された単一セグメントの音声です。転送されたメッセージと転送メッセージの両方には、送信者の話し言葉が含まれています。
To: +12145551212@vm1.mycompany.com
From: "Vaudreuil, Greg" <+19725552345@VM2.mycompany.com>
Date: Mon, 26 Aug 93 10:20:20 -0700 (CDT)
MIME-Version: 1.0 (Voice 2.0)
Content-type: Multipart/Voice-Message; Version=2.0;
Boundary="MessageBoundary"
Content-Transfer-Encoding: 7bit
Message-ID: ABCD-123456789@VM2.mycompany.com
--MessageBoundary
Content-type: Audio/32KADPCM
Content-Transfer-Encoding: Base64
Content-Disposition: inline; voice=Originator-Spoken-Name
Content-Language: en-US
Content-ID: part3@VM2-4321
glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd (This is a sample of the base-64 Spoken Name data) fgdhgd dlkgpokpeowrit09==
glslfdslsertiflktfpgktportrpktpfgtpoitpdasssdasddasdasd（これはbase-64 aceand name dataのサンプルです）fgdhgd dlkgpokpeowrit09 =====
--MessageBoundary Content-type: Audio/32KADPCM Content-Description: Forwarded Message Annotation Content-Disposition: inline; voice=Voice-Message Content-Transfer-Encoding: Base64
-MessageBoundary Content-Type：Audio/32KADPCMコンテンツデスプリシブル：転送されたメッセージアノテーションコンテンツ - ディスポジション：インライン;Voice = Voice-Message Content-Transfer-Encoding：base64
glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd (This is the voiced introductory remarks encoded in base64) jrgoij3o45itj09fiuvdkjgWlakgQ93ijkpokfpgokQ90gQ5tkjpokfgW dlkgpokpeowrit09==
glslfdslsertiflktfpgktportrpktpfgtpoitpdassdasddasdasd（これはbase64でエンコードされた有声入門的な備考です） rit09 ==
--MessageBoundary Content-type: Message/RFC822 Content-Transfer-Encoding: 7bit
- メッサージバウンダリーコンテンツタイプ：メッセージ/RFC822コンテンツ転送エンコード：7ビット
To: +19725552345@VM2.mycompany.com
From: "Parsons, Glenn, W." <+16135551234@VM1.mycompany.com>
Date: Mon, 26 Aug 93 8:23:10 -0500 (EST)
Content-type: Multipart/Voice-Message; Version=2.0;
Boundary="MessageBoundary2"
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0 (Voice 2.0)
--MessageBoundary2
Content-type: Audio/32KADPCM
Content-Transfer-Encoding: Base64
Content-Disposition: inline; voice=Originator-Spoken-Name
Content-Language: en-US
Content-ID: part6@VM2-4321
glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd (This is a sample of the base-64 Spoken Name data) fgdhgd dlkgpokpeowrit09==
glslfdslsertiflktfpgktportrpktpfgtpoitpdasssdasddasdasd（これはbase-64 aceand name dataのサンプルです）fgdhgd dlkgpokpeowrit09 =====
--MessageBoundary2 Content-type: Audio/32KADPCM Content-Disposition: inline; voice=Voice-Message Content-Transfer-Encoding: Base64
-MessageBoundary2コンテンツタイプ：Audio/32KADPCMコンテンツ - 分散：インライン;Voice = Voice-Message Content-Transfer-Encoding：base64
glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd (This is the original message audio data) fgwersdfmniwrjj jrgoij3o45itj09fiuvdkjgWlakgQ93ijkpokfpgokQ90gQ5tkjpokfgW dlkgpokpeowrit09==
glslfdslsertiflktfpgktportrpktpfgtpoitpdassdasddasdasd（これは元のメッセージオーディオデータです） eowrit09 ==
--MessageBoundary2--
--MessageBoundary2---
--MessageBoundary--
- メッサージバウンドリー -
The following example is for a DSN sent to the sender of a message by a VPIM gateway at VM1.company.com for a mailbox which does not exist.
次の例は、VM1.comPany.comのVPIM Gatewayによってメッセージの送信者に送信され、存在しないメールボックスを使用しています。
Date: Thu, 7 Jul 1994 17:16:05 -0400
From: Mail Delivery Subsystem <MAILER-DAEMON@vm.company.com>
Message-ID: <199407072116.RAA14128@vm1.company.com>
Subject: Returned voice message
To: 2175552345@VM2.mycompany.com
MIME-Version: 1.0
Content-Type: multipart/report; report-type=delivery-status;
boundary="RAA14128.773615765/VM1.COMPANY.COM"
--RAA14128.773615765/VM1.COMPANY.COM Content-type: Audio/32KADPCM Content-Description: Spoken Delivery Status Notification Content-Disposition: inline; voice= Voice-Message-Notification Content-Transfer-Encoding: Base64
-RAA14128.773615765/vm1.company.com content-type：audio/32kadpcmコンテンツデスプリシブル：音声配信ステータス通知コンテンツ配置：インライン;Voice = Voice-Message-notificationコンテンツ - 移動エンコード：base64
glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadadffsssddasdasd (This is a voiced description of the error in base64) jrgoij3o45itj09fiuvdkjgWlakgQ93ijkpokfpgokQ90gdffkjpokfgW dlkgpokpeowrit09==
glslfdslsertiflktfpgktportrpktpfgtpoitpdadadadadsssddasdasd（これはbase64のエラーの表明された説明です） =
--RAA14128.773615765/VM1.COMPANY.COM Content-type: Message/Delivery-Status
-raa14128.773615765/vm1.company.com content-type：メッセージ/配信-status
Reporting-MTA: dns; vm1.company.com
Reporting-MTA：DNS;vm1.company.com
Original-Recipient: rfc822; 2145551234@VM1.mycompany.com
Final-Recipient: rfc822; 2145551234@VM1.mycompany.com
Action: failed
Status: 5.1.1 (User does not exist)
Diagnostic-Code: smtp; 550 Mailbox not found
Last-Attempt-Date: Thu, 7 Jul 1994 17:15:49 -0400
--RAA14128.773615765/VM1.COMPANY.COM content-type: Message/RFC822
-raa14128.773615765/vm1.company.com content-type：message/rfc822
[original VPIM message goes here]
[元のVPIMメッセージはここにあります]
--RAA14128.773615765/VM1.COMPANY.COM--
-raa14128.773615765/vm1.company.com--
The following example is for an MDN sent to the original sender for a message that has been played. This delivered VPIM message was received by a corporate gateway and relayed to a unified mailbox.
次の例は、再生されたメッセージのために元の送信者に送信されたMDN用です。この配信されたVPIMメッセージは、企業のゲートウェイによって受信され、統一されたメールボックスに中継されました。
Date: Thu, 7 Jul 1994 17:16:05 -0400
From: "Greg Vaudreuil" <22722@vm.company.com>
Message-ID: <199407072116.RAA14128@exchange.company.com>
Subject: Voice message played
To: 2175552345@VM2.mycompany.com
MIME-Version: 1.0
Content-Type: multipart/report;
Report-type=disposition-notification;
Boundary="RAA14128.773615765/EXCHANGE.COMPANY.COM"
--RAA14128.773615765/EXCHANGE.COMPANY.COM Content-type: Audio/32KADPCM Content-Description: Spoken Disposition Notification Content-Disposition: inline; voice= Voice-Message-Notification Content-Transfer-Encoding: Base64
-raa14128.773615765/exchange.company.com Content-Type：Audio/32KADPCMコンテンツデスプリシス：音声処分通知コンテンツ - 分散：インライン;Voice = Voice-Message-notificationコンテンツ - 移動エンコード：base64
glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadadffsssddasdasd (Voiced description of the disposition action in base64) jrgoij3o45itj09fiuvdkjgWlakgQ93ijkpokfpgokQ90gdffkjpokfgW dlkgpokpeowrit09==
glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadadffsssddasdasd (Voiced description of the disposition action in base64) jrgoij3o45itj09fiuvdkjgWlakgQ93ijkpokfpgokQ90gdffkjpokfgW dlkgpokpeowrit09==
--RAA14128.773615765/EXCHANGE.COMPANY.COM Content-type: Message/Disposition-Notification
-raa14128.773615765/exchange.company.com content-type：message/diso-notification
Reporting-UA: gregs-laptop.dallas.company.com (Unified FooMail 3.0)
Reporting-UA：gregs-laptop.dallas.company.com（Unified Foomail 3.0）
Original-Recipient: rfc822;22722@vm.company.com
Final-Recipient: rfc822;Greg.Vaudreuil@foomail.company.com
Original-Message-ID: <199509192301.12345@vm2.mycompany.com>
Disposition: manual-action/MDN-sent-automatically; displayed
--RAA14128.773615765/EXCHANGE.COMPANY.COM Content-type: Message/RFC822
-raa14128.773615765/exchange.company.com Content-Type：Message/RFC822
[original VPIM message goes here]
[元のVPIMメッセージはここにあります]
--RAA14128.773615765/EXCHANGE.COMPANY.COM--14. Appendix C - Example Error Voice Processing Error Codes
-raa14128.773615765/exchange.company.com--14。付録C-エラー音声処理エラーコードの例
The following common voice processing errors and their corresponding status codes are given as examples. The text after the error codes is intended only for reference to describe the error code. Implementations should provide implementation-specific informative comments after the error code rather than the text below.
次の一般的な音声処理エラーとそれらの対応するステータスコードは、例として示されています。エラーコードの後のテキストは、エラーコードを記述するための参照のみを目的としています。実装は、以下のテキストではなく、エラーコードの後に実装固有の有益なコメントを提供する必要があります。
Error condition RFC 1893 Error codes
----------------------------- --------------------------------
Analog delivery failed 4.4.1 Persistent connection error because remote system is busy - busy
アナログ配信が失敗しました4.4.1リモートシステムがビジーなので永続的な接続エラー - ビジー
Analog delivery failed 4.4.1 Persistent protocol error because remote system is - no answer from host ring-no-answer
アナログの配信が失敗しました4.4.1リモートシステムはホストリングからの答えがないため、永続的なプロトコルエラー
Remote system did not answer 5.5.5 Permanent protocol error AMIS-Analog handshake ("D" in - wrong version response to "C" at connect time)
リモートシステムは5.5.5永久的なプロトコルエラーAMIS -Analogハンドシェイク（ "d" in -connect時期の「c」に対する間違ったバージョンの応答）に答えませんでした）
Mailbox does not exist 5.1.1 Permanent mailbox error - does not exist
メールボックスは存在しません5.1.1永久メールボックスエラー - 存在しません
Mailbox full or over quota 4.2.2 Persistent mailbox error - full
メールボックスフルまたはオーバークォータ4.2.2永続的なメールボックスエラー - フル
Disk full 4.3.1 Persistent system error - full
ディスクフル4.3.1永続的なシステムエラー - フル
Command out of sequence 5.5.1 Permanent protocol error - invalid command
シーケンスからのコマンド5.5.1永続的なプロトコルエラー - 無効なコマンド
Frame Error 5.5.2 Permanent protocol error - syntax error
フレームエラー5.5.2永久プロトコルエラー - 構文エラー
Mailbox does not support FAX 5.6.1 Permanent media error - not supported
メールボックスはFAX 5.6.1永久メディアエラーをサポートしていません - サポートされていません
Mailbox does not support TEXT 5.6.1 Permanent media error - not supported
メールボックスはテキストをサポートしていません5.6.1永久メディアエラー - サポートされていません
Sender is not authorized 5.7.1 Permanent security error - sender not authorized
送信者は許可されていません5.7.1恒久的なセキュリティエラー - 送信者は許可されていません
Message marked private, but 5.3.3 Permanent system error system is not private capable - not feature capable
プライベートとマークされたメッセージですが、5.3.3永久システムエラーシステムはプライベート機能ではありません - 機能は機能しません
The following common voice processing disposition conditions and their corresponding MDN Disposition (which contains the disposition mode, type and modifier, if applicable) are given as examples. Implementers should refer to [MDN] for a full description of the format of message disposition notifications.
次の一般的な音声処理処理条件と、対応するMDN処置（該当する場合は、処分モード、タイプ、および修飾子が含まれます）を例として示します。実装者は、メッセージ処分通知の形式を完全に説明するために[MDN]を参照する必要があります。
Notification event MDN Disposition mode, type & modifier
------------------------------ ------------------------------------
Message played by recipient, manual-action/MDN-sent-automatically; receipt automatically returned displayed
受信者が再生するメッセージ、手動アクション/MDN-Sent-automatical;領収書は自動的に表示されます
Message deleted from mailbox manual-action/MDN-sent-automatically; by user without listening deleted
Mailbox Manual-action/MDN-Sent-automaticで削除されたメッセージ。削除されているのを聞くことなくユーザーによって
Message cleared when mailbox manual-action/MDN-sent-automatically; deleted by admin deleted/mailbox-terminated
Mailbox Manual-action/MDN-Sent-automaticalでメッセージがクリアされました。admin削除/メールボックス終端によって削除されます
Message automatically deleted automatic-action/ when older than administrator MDN-sent-automatically; deleted/ set threshold expired
メッセージは自動的に削除されました。削除/設定しきい値が切れました
Message processed, however manual-action/MDN-sent-automatically; audio encoding unknown - processed/error unable to play to user Error: unknown audio encoding
メッセージ処理されますが、手動アクション/mdn-sent-automaticで。オーディオエンコーディング不明 - 処理済み/ユーザーに再生できないエラーエラー：不明なオーディオエンコーディング
There are no changes to the registration per [DISP] of the voice content disposition parameter defined in the earlier VPIM V2 document, RFC 2421. There are no changes to the registration per [MIME4] of the Multipart/voice-message content type defines in the earlier VPIM v2 document, RFC 2423.
以前のVPIM V2ドキュメントRFC 2421で定義された音声コンテンツ処分パラメーターの[Disp]ごとの登録に変更はありません。以前のVPIM V2ドキュメント、RFC 2423。
Both are presented here for information.
両方とも情報についてはここに示されています。
To: IANA@IANA.ORG
宛先：iana@iana.org
Subject: Registration of new Content-Disposition parameter
件名：新しいコンテンツ拡散パラメーターの登録
Content-Disposition parameter name: voice
コンテンツ - 分散パラメーター名：音声
Allowable values for this parameter:
このパラメーターの許容値：
Voice-Message - the primary voice message, Voice-Message-Notification - a spoken delivery notification or spoken disposition notification, Originator-Spoken-Name - the spoken name of the originator, Recipient-Spoken-Name - the spoken name of the recipient if available to the originator and present if there is ONLY one recipient, Spoken-Subject- the spoken subject of the message, typically spoken by the originator
音声メッセージ - プライマリボイスメッセージ、音声メッセージノーティフィケーション - 音声配信通知または音声処分通知、オリジネーターのスポークン名 - オリジネーターの話された名前、受信者のスポーク名 - 受信者の話された名前の場合オリジネーターが利用でき、受信者が1人しかいない場合は現在、話された主題 - メッセージの話された主題、通常はオリジネーターが話しています
Description:
説明：
In order to distinguish between the various types of audio contents in a VPIM voice message a new disposition parameter "voice" is defined with the preceding values to be used as appropriate. Note that there SHOULD only be one instance of each of these types of audio contents per message level. Additional instances of a given type (i.e., parameter value) may occur within an attached forwarded voice message.
VPIM音声メッセージ内のさまざまなタイプのオーディオコンテンツを区別するために、新しい気質パラメーター「音声」は、必要に応じて使用される前の値で定義されます。メッセージレベルごとに、これらのタイプのオーディオコンテンツのそれぞれに1つのインスタンスしかない必要があることに注意してください。特定のタイプの追加インスタンス（つまり、パラメーター値）が添付された転送された音声メッセージ内で発生する場合があります。
To: ietf-types@iana.org Subject: Registration of MIME media type Multipart/voice-message
宛先：ietf-types@iana.org件名：Mime Media Type MultiPart/Voice-Messageの登録
MIME media type name: multipart
MIMEメディアタイプ名：MultiPart
MIME subtype name: voice-message
MIMEサブタイプ名：音声メッセージ
Required parameters: boundary, version
必要なパラメーター：境界、バージョン
The use of boundary is defined in [MIME2] The version parameter that contains the value "2.0" if enclosed content conforms to [VPIM2R2]. The absence of this parameter indicates conformance to the previous version defined in RFC 1911 [VPIM1].
境界の使用は、囲まれたコンテンツが[VPIM2R2]に適合する場合、[MIME2]の値「2.0」を含むバージョンパラメーターで定義されます。このパラメーターがないことは、RFC 1911 [VPIM1]で定義された以前のバージョンへの適合を示しています。
Optional parameters: none
オプションのパラメーター：なし
Encoding considerations: 7bit, 8bit or Binary
考慮事項のエンコード：7ビット、8ビット、またはバイナリ
Security considerations:
セキュリティ上の考慮事項：
This definition identifies the content as being a voice message. In some environments (though likely not the majority), the loss of the anonymity of the content may be a security issue.
この定義は、コンテンツが音声メッセージであると識別します。一部の環境では（大多数ではない可能性が高い）、コンテンツの匿名性の損失がセキュリティの問題になる可能性があります。
Interoperability considerations:
相互運用性の考慮事項：
Systems developed to conform with [VPIM1] may not conform to this registration. Specifically, the required version will likely be absent, in this case the recipient system should still be able to accept the message and will be able to handle the content. The VPIM v1 positional identification, however, would likely be lost.
[VPIM1]に準拠するように開発されたシステムは、この登録に適合しない場合があります。具体的には、必要なバージョンが欠けている可能性があります。この場合、受信者システムはまだメッセージを受け入れることができ、コンテンツを処理できるようになります。ただし、VPIM V1の位置識別はおそらく失われる可能性があります。
Published specification: This document
公開された仕様：このドキュメント
Applications that use this media type:
このメディアタイプを使用するアプリケーション：
Primarily voice messaging
主に音声メッセージング
Additional information:
追加情報：
Magic number(s): none
File extension(s): .VPM
Macintosh File Type Code(s): VPIM
Person & email address to contact for further information:
詳細については、連絡先への個人およびメールアドレス：
Glenn W. Parsons gparsons@nortelnetworks.com
Glenn W. Parsons gparsons@nortelnetworks.com
Gregory M. Vaudreuil gregv@ieee.org
Gregory M. Vaudreuil gregv@ieee.org
Intended usage: COMMON Author/Change controller:
意図された使用法：共通の著者/変更コントローラー：
Glenn W. Parsons & Gregory M. Vaudreuil
グレン・W・パーソンズ＆グレゴリーM.ヴォードルイユ
The updated profile in this document is based on the implementation and operational deployment experience of several vendors. The changes are categorized as general, content, transport and conformance. They are summarized below:
このドキュメントの更新されたプロファイルは、いくつかのベンダーの実装および運用展開エクスペリエンスに基づいています。変更は、一般、コンテンツ、輸送、適合に分類されます。それらは以下に要約されています：
1. General
1. 一般的な
- Various and substantial editorial updates to improve readability.
- 読みやすさを改善するためのさまざまな実質的な編集上の更新。
- Separated send rules from receive rules to aid clarity.
- 明確さを支援するために、ルールを受け取るルールからルールを送信します。
- Clarified the behavior upon reception of unrecognized content types expected with the interworking between voice and unified messaging systems. (E.g., Unsupported non-audio contents should be discarded to deliver the audio message.)
- 音声と統一されたメッセージングシステムの間のインターワーキングで、予想される認識されていないコンテンツタイプを受信すると、動作を明らかにしました。（たとえば、サポートされていない非オーディオコンテンツは、オーディオメッセージを配信するために破棄する必要があります。）
- Reworked the sensitivity requirements to align them with X.400. Eliminated dependencies upon the MIXER documents.
- 感度要件を再加工して、それらをx.400に合わせました。ミキサードキュメントへの依存関係を排除しました。
- Reorganized the content-type descriptions for clarity
- 明確にするために、コンテンツタイプの説明を再編成しました
2. Content
2. コンテンツ
- Changed handling of received lines by a gateway to SHOULD NOT delete in a gateway. In gateways to systems such as AMIS, it is not possible to preserve this information. It is intended that such systems be able to claim conformance.
- ゲートウェイのゲートウェイで受信したラインの処理を変更して、ゲートウェイで削除しないでください。AMISなどのシステムへのゲートウェイでは、この情報を保存することはできません。そのようなシステムは、適合を請求できることを意図しています。
- Eliminated the vCard as a supported VPIM V2 content type.
- サポートされているVPIM V2コンテンツタイプとしてVCardを排除しました。
- Merged in text from RFC 2423 (Multipart/voice-message)
- RFC 2423からのテキストでマージされました（MultiPart/Voice-Message）
3. Transport
3. 輸送
- None
- なし
4. Conformance
4. 適合
- Aligned the table of Appendix A to the requirements in the text.
- 付録Aの表をテキストの要件に合わせました。
Gregory M. Vaudreuil Lucent Technologies 7291 Williamson Rd Dallas, TX 75214 United States
Gregory M. Vaudreuil Lucent Technologies 7291 Williamson Rd Dallas、TX 75214米国
EMail: gregv@ieee.org
Glenn W. Parsons Nortel Networks P.O. Box 3511, Station C Ottawa, ON K1Y 4H7 Canada
グレン・W・パーソンズ・ノルテル・ネットワークP.O.ボックス3511、ステーションCオタワ、K1Y 4H7カナダ
Phone: +1-613-763-7582
Fax: +1-613-763-2697
EMail: GParsons@NortelNetworks.com
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
著作権（c）The Internet Society（2004）。この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。