RFC 3801 - Voice Profile for Internet Mail - version 2 (VPIMv2) 日本語訳

URL : https://tools.ietf.org/html/rfc3801
タイトル : RFC 3801 - インターネットメール用の音声プロファイル - バージョン2（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)

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）の最新版を参照してください。このメモの配布は無制限です。

著作権表示

著作権（C）インターネット協会（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

1. Introduction

1. はじめに

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のこのバージョンのプロトコルプロフィールをまとめました。

1.1. Voice Messaging System Limitations

1.1. ボイスメッセージシステムの制限

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に基づいており、これらの制限を受けないことに留意すべきです。特に、いくつかのシステムは、音声およびファックス以外のメディアをサポートすることができます。

1.2. Design Goals

1.2. 設計目標

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メッセージングシステムを管理することが期待されます。ファクシミリまたは複数の音声符号化方式を使用する場合は、システム管理者が機能のサポートが不足しているため、配信不能メッセージの送信を削減するために、ネットワークに接続し、メールのマシンの能力のリストを維持することが示唆されました。これらのディレクトリ・リスト機能の設定、実装と管理は、地元の問題です。

1.3. Applicability for VPIM

1.3. 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は、メッセージストアサーバと、ウェブサーバ、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システムに汎用クライアントからの音声メッセージの提出に適したフォーマットであってもよいです。

2. Requirements Language

2.必要な言語

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].

この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[REQ]で説明されるように解釈されます。

3. Protocol Restrictions

3.プロトコルの制限

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.

このプロトコルは、メッセージの最大長を制限するものではありません。実装者はいくつかのマシンが過度に長いメッセージを受け入れることができないだろうことを理解すべきです。機構は[SIZE]で定義されているサポートされる最大メッセージサイズを宣言します。

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の表は、このプロファイルのプロトコルの詳細をまとめたもの。

4. Voice Message Interchange Format

4.ボイスメッセージ交換フォーマット

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].

音声メッセージ交換フォーマットは、インターネットメールプロトコルスイートのプロファイルです。このセクションで定義された形式を含む任意のインターネットメールメッセージは、この文書に記載されているVPIMメッセージと呼ばれます。その結果、このドキュメントは、インターネットメールの仕様の理解を前提としています。インターネットメッセージのメッセージフォーマット規格から具体的には、VPIM参照成分[RFC822]、多目的インターネットメッセージ拡張[MIME1-5]、X.400ゲートウェイ仕様[X.400]、および送達ステータスとメッセージ気質通知[REPORT ] [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 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は、7ビット表現、テキストのようなデータ（「引用符で囲まれた印刷可能」）のために設計された1つ、及び任意のバイナリデータ（「Base64で」）のための1つにバイナリデータを変換するために、2つのトランスポート符号化メカニズムを定義しています。 Base64では、オーディオデータのために劇的に、より効率的ですが、どちらかが動作します。バイナリトランスポートが利用可能である場合、何の輸送エンコーディングが必要とされず、データは「バイナリ」として標識することができます。

4.1. VPIM Message Addressing Formats

4.1. フォーマットへの対応VPIMメッセージ

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つのコンポーネントがありますローカル部分は、ユーザ名またはメールボックスの識別に使用します。そして、ホスト部には、グローバルなマシンの識別に使用します。

4.1.1. VPIM Addresses

4.1.1. VPIMアドレス

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桁の電話のキーパッドとの互換性を保持するために、数値のメールボックス識別子に依存しているように、短い数字のローカル部品を使用する必要があります。その結果、いくつかのボイスメッセージシステムは、数字のみローカル部分を処理することができるかもしれません。これらのシステム上の英数字のローカル部分の受信は、いくつかの局所的に一意の（しかし、受信者に混乱）番号またはアドレスは、メッセージがunreplyable作る削除することができる最悪の場合にマッピングされるアドレスをもたらし得ます。さらに、複雑なキーシーケンスなしの英数字ローカル一部またはディレクトリ検索のいくつかのフォーム（6を参照）で、これらのシステム上でメッセージを作成することは困難です。ドメインネームシステムの使用は、ユーザーに透明であるべきです。（6を参照）、ユーザが入力したアドレスに基づいて、完全修飾ドメイン名（FQDN）を検索するためにボイスメールマシンの責任です。

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

2）メールボックスの数+拡張 - 拡張専用番号プランの桁の任意の数として使用するための、セパレータとして「+」を使用する - 例えば、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）+国際番号 - 国際電話番号は15桁のE.164最大に準拠する方法 - 例えば、+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

4）+国際番号+内線 - 国際電話番号は、PBXの後ろに拡張子（例えば、で、15桁のE.164最大に適合するための）15桁の最大値を有します。 - 例えば、+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.

このアドレス形式は、音声メッセージング業界内で現在の使用と互換性があるように設計されていることに注意してください。これは、2303年から2304年のRFCのアドレッシング・フォーマットと互換性がありません。電話サービスは、インターネット上でより広範囲になると、これらのアドレス指定形式が収束することが期待されます。

4.1.2. Special Addresses

4.1.2. 特殊アドレス

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:

送信者を表現するために特別なアドレスはインターネットメールの規則との互換性のために提供されています。これらのアドレスは、両方のは、現在のインターネットの練習に適合するように、既存の数値取り組む計画との競合を避けるために、数値のローカルアドレスを使用しないでください。次のように二つの特別なアドレスが使用するために予約されています。

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

メール以外のユーザー@ドメイン

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>

From：<non-mail-user@mycompany.com>電話応答

4.1.3. Distribution Lists

4.1.3. 配布リスト

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の実装では、配布リストをサポートするかもしれません。簡単な別名を使用すると、多くのボイスメールシステムは、今日やるとVPIMメッセージで使用するために何が何であるかに最も近い動作です。 DLが使用された場合、特別なケアを必要とする重要な機能のカップルは、次のとおりです。

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)

発信元に返信する - （RFC822でアドレスが「返信先：」または「From」フィールド）エラー提出者に - （ESMTP交換や分野、MAIL FROMでのアドレス「リターンパス：」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.

いくつかの独自のボイスメッセージングプロトコルは、エンベロープ内の特定のコピーの受信者のみを含めると、日付とメッセージごとの機能以外に、「ヘッダフィールド」が含まれていません。ほとんどの音声メッセージングシステムは、そのメッセージ・キューに「ヘッダ情報」を提供し、唯一の配信情報が含まれていません。または「CC：」ヘッダフィールド：結果として、受信者情報「は、」いずれかであってもよいです。すべての受信者は、次に提示することができない場合、受信者ヘッダフィールドは、受信者の正確なリストを（例えば、返信すべての機能で使用するために）知られていないことを示すために省略されるべきです。

4.2. Message Header Fields

4.2. メッセージヘッダフィールド

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メッセージで使用するために許可されています。

4.2.1. From

4.2.1. から

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： "ジョーS.ユーザー" <12145551212@mycompany.com>

From: Technical Support <611@serviceprovider.com>

投稿者：テクニカルサポート<611@serviceprovider.com>

From: Non-mail-user@myserver.mycompany.com

投稿者：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.

VPIM準拠のシステムでは、FROMヘッダフィールドとSMTPのMAILが同じアドレスにこれらの値を設定する必要があります。ボイスメールマシンは、「差出人」用に別の属性をサポートすることができないかもしれません。「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).

正確なプレゼンテーションが実装決定（例えば、メールボックスのIDであるか、テキスト名をしてもよいが、フィールドには、メッセージの発信元として、ボイスメッセージングシステムの音声メッセージエンベロープに提示しなければならない：「から」にリストされているユーザー提示）。「From：」のアドレスは（4.9を参照）の応答のために使用されるべきです。

4.2.2. To

４。２。２。と

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.

任意のメッセージ内のフィールド：「へ」一つ以上があるかもしれません。システムは、すべての受信者が利用可能な場合にのみ、受信者のリストを提供すべきです。

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.

ライン：そのような「へ」を提供することができるが、受信者の完全なリストを示していないプロトコルまたはレガシープラットフォームからゲートウェイなどのシステム、。これらのシステムは正確に「：を」内のすべての受信者を列挙することはできませんので、ヘッダー、受信者が列挙されるべきではありません。

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.

彼らは情報を保存することができない場合フィールド：このプロファイルに準拠したシステムは、「へ」でアドレスを捨てるかもしれ。これは、当然のことながら、返信対全機能が不可能になるだろう。存在する場合は、「宛先：」のアドレスフィールドには、すべての受信者への返信メッセージのために使用されるかもしれません。

4.2.3. Cc

4.2.3. CC

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

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」内のすべてのアドレスを追加するかもしれません。「CC：」のリスト場合はアドレスが存在し、これらのアドレスは、すべての受信者への返信メッセージのために使用されるかもしれません。

4.2.4. Date

4.2.4. 日付

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）」、括弧内のタイムゾーン名で補足することができます。

The "Message-Id:" field contains a globally unique per-message identifier.

「メッセージ-ID：」フィールドには、グローバルに一意のメッセージごとの識別子が含まれています。

SEND RULES

ルールを送信

A globally unique message-id MUST be generated for each message sent from a VPIM-conforming implementation.

グローバルに一意のメッセージIDは、VPIM準拠の実装から送信される各メッセージのために生成しなければなりません。

Example:

例：

Message-Id: <12345678@mycompany.com>

メッセージID：<12345678@mycompany.com>

RECEIVE 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]

VPIM準拠の実装では、メッセージの感度を示すため、このヘッダを含むかもしれません。ユーザーは「プライベート」メッセージをマークした場合は、適合する実装は唯一の「プライベート」感度レベルを送らなければなりません。値が「個人」または「当社-秘密」に定義されたVPIM固有の意味がありません。準拠した実装では、「個人」または「当社-秘密」の値を送るべきではありません。メッセージは、「通常」感度である場合、このフィールドは省略されるべきです。 From：[X.400]

RECEIVE RULES

ルールを受け取ります

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.

「感度：」場合は「プライベート」の値を持つフィールドがメッセージ内に存在する、適合システムは、他のユーザにこのメッセージを転送から受信者を禁止しなければなりません。適合システムは、しかし、応答が敏感メッセージに返信することを可能にするべきであるが、元のメッセージの内容を含むべきではありません。応答は、応答メッセージの感度を設定することができます。

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.

プライバシーなしでメッセージが明示的に指摘し（すなわち、全くヘッダ）または「標準」感度とは、特別な治療を持っていません。

4.2.14. Importance

4.2.14. 重要性

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.

受信システムがサポートされていない場合は、「重要性：」、属性が黙って捨てられるかもしれません。

4.2.15. Subject

4.2.15. 主題

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.

テキストベースのメールボックス・インターフェースとの互換性のために、テキストの件名フィールドは、適合実装によって生成されるべきです。任意のテキスト・ユーザ・インターフェースをサポートしていないボイスメールシステム（電話のみによって、例えば、アクセス）はGUIが有効な受信者の利益のために、「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.

多くの音声のみのシステムは、件名を保存することができないことが予想されます。被験者は、受信システムによって破棄されるかもしれません。

4.3. MIME Audio Content Descriptions

4.3. MIMEオーディオコンテンツの説明

4.3.1. Content-Description

4.3.1. コンテンツの説明

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.

このフィールドは、受信者に表示することができます。それだけで有益であるので、しかし、それは無視してもよいです。

4.3.2. Content-Disposition

4.3.2. コンテンツ処分

   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]

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

音声メッセージ - 主音声メッセージ、音声メッセージ通知 - 話さ配信通知または話さ処分の通知、発信・音声・名前 - 発信者の音声名、受信者 - 音声 - [名前] - 受信者の音声名（ -サブジェクト音声発信秒）利用可能な場合は、メッセージの件名話され、典型的には発信者によって話さ

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.

実装は、このヘッダを使用するべきです。しかし、「声」パラメータ（または「コンテンツディスポジション：」ヘッダを）理解していないものは、安全にそれを無視することができ、そして順序でオーディオ身体の部分を提示する（しかし、これらを区別することはできません）。「音声」パラメータタイプ値の複数のインスタンスが（例えば、複数の「ボイスメッセージ」の内容をタグ付け）1つのレベルで検出された場合、それらは一緒に提示されるべきです。

4.3.3. Content-Duration

4.3.3. コンテンツ持続時間

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. コンテンツ言語：

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

コンテンツ言語：EN-英国

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.

レセプションでこのフィールドの使用はローカルの導入問題です。これは、音声メッセージの言語のような受信者（例えば、エンドユーザ又は自動翻訳プロセス）へのヒントとして使用されてもよいです。

4.4. Voice Message Content Types

4.4. ボイスメッセージのコンテンツタイプ

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".

このセクションで説明するコンテンツタイプはマルチパート/ボイスメッセージのコンテンツ内で使用するために識別されます。このコンテンツは、本書では「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.

プロファイルのみ内容は、単純なまたはより複雑な構造を（いくつかの例は、付録Bに記載されている）を形成するためにVPIMボイスメッセージ構築物（すなわち、マルチパート/ボイスメッセージのコンテンツタイプ）内で送信することができます。 VPIMボイスメッセージ内の他のコンテンツの存在が許されません。二国間の合意がない場合には、適合実装は禁止された内容を含むメッセージを作成してはいけません。リベラル受け入れの精神では、適合実装は受け入れて、禁止されたコンテンツをレンダリングするかもしれません。受け入れるか、または許容可能なコンテンツを配信するために、必要に応じて禁止内容を捨てるかもしれ禁止のコンテンツをレンダリングするシステムができません。複数のコンテンツをマルチパート/音声メッセージ内に存在する場合、彼らはメッセージに表示される順序でユーザに提示されるべきです。

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の仕様の共通の解釈に基づいていくつかの展開の実装は禁止されたコンテンツとのメッセージを拒否ではなく、サポートされていない内容を破棄します。これらのシステムとの相互運用性のために、禁止された内容は、マルチパート/ボイス・メッセージ内で送信されないことが特に重要です。

4.4.1. Multipart/Voice-Message

4.4.1. マルチパート/音声メッセージ

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適合としてタグ付けされている一つの容器に音声メッセージをパッケージ化するためのメカニズムを提供します。サブタイプは、[MIME2]で定義されるように、multipart / mixedのために意味論と構文に同一です。このように、安全に、サブタイプを理解していないシステムによって混合マルチパート/（音声メッセージとしてのみ識別が失われる）として解釈することができます。

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).

MIME必要な境界パラメータに加えて、バージョンパラメータは、このサブタイプのために必要とされます。これは、[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.

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として知られているファクシミリのための一般的な画像符号化は、タグイメージファイル形式（TIFF）の誘導体であり、いくつかの文献に記載されています。 VPIMの目的のために、ファクシミリ用TIFFのFプロフィール（TIFF-F）は、[TIFF-F]で定義され、そして画像/ TIFFのMIMEコンテンツタイプは、[TIFFREG]で定義されています。 TIFFのいくつかの形式がありますが、唯一のTIFF-Fは、マルチパート/ボイス・メッセージ内で使用するためにプロファイルされています。 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メッセージはvoice-注釈付きファックスの場合は、実装は、マルチパート/音声メッセージでこのファックスコンテンツを送るべきです。メッセージが単純なファックスである場合、実装は、ファックス専用（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システムサポートファックス、すべてがマルチパート/ボイスメッセージの中でそれを受け入れる必要があります。マルチパート/音声メッセージ内、ファックスコンテンツをレンダリングすることはできません受信システムは、VPIMメッセージの音声内容を受け入れ、ファックス内容を捨てます。それは保管しないまたはFAX添付ファイル付きのメッセージをレンダリングすることはできないことができるかどうかマルチパート/ボイス・メッセージの外では、受信側システムは、（適切なNDNとの）メッセージ全体を拒否するかもしれません。 VPIM準拠したシステムは、マルチパート/ボイス・メッセージの（またはなし）の外にファックスをサポートするかもしれません。

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仕様の共通の解釈に基づいていくつかの展開の実装はマルチパート/ボイス・メッセージ内のファックスコンテンツにメッセージを拒否ではなく、サポートされていない内容を破棄します。これらのシステムは、ファックスのサポートのNDN示す欠如と送信者にメッセージを返します。

4.5. Other MIME Contents

4.5. その他のMIME内容

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).

（セクション4.5.1で混合/マルチパートを除く）は、以下のMIMEコンテンツは、マルチパート/ボイスメッセージ内に含めることができます。その他の内容は含んではいけません。彼らの取り扱いはローカルの導入問題です。混合/マルチパートは、システムの広い範囲との相互運用性を促進し、また（一部としてVPIMメッセージで）より複雑なマルチメディアメッセージの作成を可能にするために含まれています。

4.5.1. Multipart/Mixed

4.5.1. ミックス/マルチパート

This common MIME content-type allows the enclosing of several body parts in a single message.

この共通のMIMEコンテンツタイプは、単一のメッセージ内のいくつかの身体の部分の封入を可能にします。

4.5.4. テキスト/平野

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文字セットと）基本的なtext / plainのコンテンツ・タイプのサポートが必要です。このコンテンツタイプは、ボイスメッセージング環境内の限られた利用可能性を有します。 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の実装は、text / plainのコンテンツタイプを送るべきではありません。実装は、マルチパート/音声メッセージの外にtext / plainのコンテンツタイプを送信することができます。

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.

必要に応じてマルチパート/ボイス・メッセージの中では、text / plainのコンテンツタイプは、オーディオ/ファックスコンポーネントを提供するために、メッセージから削除できます。テキストコンポーネントが受け入れ又はレンダリングすることができない場合、受信者はメッセージ全体を拒否すべきではありません。

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示す欠如と送信者にメッセージを返します。

4.6. Delivery Status Notification (DSN)

4.6. 配信状態通知（DSN）

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のトップレベルのコンテンツ・タイプは[REPORT]で定義されるマルチパート/報告、です。通知の他の種類の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に準拠した実装は[REPORT]と[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に準拠した実装は[REPORT]と[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の目的は、エンドユーザに提示しなければなりません。

4.7. Message Disposition Notification (MDN)

4.7. メッセージ気質通知（MDN）

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は、（受信者がなど、それを見ることができる前にメッセージが削除された）正（メッセージが読まれたの/ etc /レンダリング/演奏。）または負になることができます。 MDNのトップレベルのコンテンツ・タイプは[REPORT]で定義されるマルチパート/報告、です。通知の他のタイプの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に準拠した実装は、開封通知を要求する能力をサポートする必要があります。 [MDN]で定義されるヘッダフィールド：これは、「処分-NOTIFICATION-へ」の使用を介して行われます。

A VPIM-compliant implementation SHOULD support the ability to send MDNs, but these MDNs MUST conform to [REPORT] and [MDN].

VPIMに準拠した実装は、開封通知を送信する機能をサポートする必要がありますが、これらの開封通知は[REPORT]と[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準拠の実装は、それが開封通知を要求することが可能である場合、[REPORT]と[MDN]に準拠開封通知を受け取ることができなければなりません。 VPIMに準拠した実装は、開封通知を受信することが可能であるならば、その「人間が読める」身体の部分話さメッセージ気質のフレーズやテキストの配置記述が含まれているMDNを受け取ることができなければなりません。フレーズやテキストのその後の使用はローカルの導入問題ですけれども、MDNの目的は、エンドユーザに提示しなければなりません。

4.8. Forwarded Messages

4.8. 転送されたメッセージ

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は、明示的に音声またはファックス注釈付き音声およびファックスコンテンツの転送をサポートしています。しかし、のみ以下に説明する2つの構築物は、VPIMメッセージに許容可能です。（すなわち、メッセージ/ 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]

   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.

4.9. Reply Messages

4.9. メッセージの返信

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メッセージをゲートウェイ処理するときだけ選択する必要があるかもしれません。しかし、実装者は、これはそれが不可能彼らの適切な宛先に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フィールド（4.1.2を参照）特別なアドレス非メールのユーザ@ドメインを含むべきです。（ - VPIMの範囲外である外部呼出し機能が提供されていない限り）、受信者のVPIMシステムは、この種のメッセージに返信するオプションを提供すべきではありません。

5. Message Transport Protocol

5.メッセージトランスポートプロトコル

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は、メールを送信すると、端末のコンソールメッセージングを許可するように設計された両方の汎用メッセージングプロトコルです。簡易メール転送プロトコル（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コマンド、キーワード、および必要とされるパラメータとこのプロファイルへの適合のためのオプションのあるもの。

5.1. Base SMTP Protocol

5.1. 基本SMTPプロトコル

A conforming system MUST implement all mandatory SMTP and ESMTP commands. Any defined optional command or parameter MAY be supported.

準拠したシステムは、すべての必須SMTPおよびESMTPのコマンドを実行しなければなりません。任意の定義されたオプションのコマンドまたはパラメータをサポートすることができます。

5.2. SMTP Service Extensions

5.2. SMTPサービス拡張

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で使用するためにプロファイルされています。

5.2.1. DSN Extension

5.2.1. DSN拡張

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）は、DSNのは、特定の条件下で生成されるべき指定することを可能にする機構、（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コマンドでパラメータをNOTIFYサポートしなければなりません。 RETパラメータは、通知に元のメッセージを返すようにサポートされる必要があります。パラメータORCPTとENVIDもサポートされるかもしれません。 From：[DRPT]

5.2.2. SIZE Extension

5.2.2. サイズ拡張

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]

SIZE拡張は、SMTPクライアントとサーバは、サーバにメッセージサイズのクライアントの推定値に基づいてメッセージを（おそらく一時的に）受け入れを拒否する機会を与えるために相互作用できる機構を定義します。 From：[SIZE]

The SIZE extension MUST be supported by VPIM-compliant implementations.

SIZE拡張は、VPIM準拠の実装でサポートしなければなりません。

5.2.3. ENHANCEDSTATUSCODES Extension

5.2.3. ENHANCEDSTATUSCODES拡張

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：[STATUS]

The ENHANCEDSTATUSCODES extension SHOULD be supported by VPIM-compliant implementations.

ENHANCEDSTATUSCODES拡張は、VPIM準拠の実装によってサポートされる必要があります。

5.2.4. PIPELINING Extension

5.2.4. PIPELINING拡張

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のパフォーマンスを大幅に向上させることができます。 [PIPE]から

The PIPELINING extension SHOULD be supported by VPIM-compliant implementations.

PIPELINING拡張子はVPIM準拠の実装によってサポートされる必要があります。

5.2.5. CHUNKING Extension

5.2.5. CHUNKING拡張

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]

CHUNKING拡張を効率的に大きいMIMEメッセージを送信するためのメッセージデータ転送コマンドの使用（DATAコマンドの代わりに）「BDAT」を交渉するSMTPクライアントとサーバーを可能にするメカニズムを定義します。 From：[BINARY]

The CHUNKING extension MAY be supported by VPIM-compliant implementations.

CHUNKING拡張子はVPIM準拠の実装によってサポートされるかもしれません。

5.2.6. BINARYMIME Extension

5.2.6. BINARYMIME拡張

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拡張は、BDATコマンドを利用してエンコードされていないバイナリメッセージデータの転送をネゴシエーションするようにSMTPクライアントとサーバーを可能にするメカニズムを定義します。 From：[BINARY]

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がサポートされる場合、その後、CHUNKINGが定義によってサポートされなければならないことを指定することに注意してください。

5.3. ESMTP - SMTP Downgrading

5.3. ESMTP - SMTPのダウングレード

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つのカテゴリに分類されます。最初のカテゴリは、SIZE、BINARYMIME、とパイプラインなどの搬送システムの効率を向上させる機能を備えています。あまり機能輸送システムへのダウングレードが発生した場合には、これらの機能は、送信者または受信者には機能変更に落下させることができます。

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.

機能の第二のカテゴリーは、新しい機能をサポートするトランスポートの拡張機能です。 DSNとENHANCEDSTATUSCODESは、ボイスメールに期待される信頼性のレベルに電子メールを持って配信状態通知の取り扱いに不可欠な改善をもたらします。イントラネットまたはグローバルなインターネットを介したサービスの一貫したレベルを確保するためには、VPIM準拠ESMTPは、システムを元のVPIMと受信側システム間のすべてのホップでのDSN拡張をサポートすることが不可欠です。「ダウングレード」は、中継ホップが配信状態通知のためのESMTP要求なしVPIMメッセージを転送する（次のホップによって）強制されてもよい避けられない状況です。ダウングレードシステムがメッセージを配信しようとし続けることが推奨されていますが、元に適切な配信状態通知を送らなければなりません、例えば、メッセージは、ESMTPホストを離れ、非DSN-意識先に中継送信された、とこれは、最後のDSNを受信することができます。

6. Directory Address Resolution

6. Directoryのアドレス解決

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でない場合）、ユーザーが入力したアドレスに基づいて、受信者の完全修飾ドメイン名（FQDN）を提供するために、VPIMシステムの責任です。これは、一般的にのみ電話ユーザインターフェイスを提供するシステム上の問題だろう。宛先システムへの送達を可能にするルーティング可能な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メッセージのヘッダフィールドから解析されたアドレスまたは名前がディレクトリを移入するために使用されるかもしれません。

7. Management Protocols

7.管理プロトコル

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準拠のマシンでサポートされる必要があります。

7.1. Network Management

7.1. ネットワーク管理

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]のレポートを提供するために実施することができます。

8. Conformance Requirements

8.適合性要件

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.

輸送およびコンテンツ：すべての環境に適応するために、この文書は、適合の二つの領域を定義します。

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輸送準拠であることが期待されます。

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.

コンテンツ準拠のシステムは、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エンドシステムは、transport-とコンテンツ準拠の両方であると予想されます。ボイスメッセージングシステムとプロトコル変換ゲートウェイは、エンドシステムと考えられています。

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輸送能力から利益を得ることができる一方で、特定のクライアント・サーバーの要件は、この文書の範囲外のです。

9. Security Considerations

9.セキュリティの考慮事項

9.1. General Directive

9.1. 一般的な指令

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.

この文書では、既存のインターネットメールプロトコルのプロフィールです。インターネットメールとの相互運用性を維持するために、提供されるすべてのセキュリティは、インターネット・セキュリティ・インフラストラクチャの一部ではなく、新しい機構やインターネットインフラストラクチャの外側にいくつかの他のメカニズムである必要があります。

9.2. Threats and Problems

9.2. 脅威と問題点

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つのサービスを統合することから、結果として起きる追加脅威のセットに参加しています。

9.2.1. Spoofed sender

9.2.1. 偽装された送信者

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.

または「から：」メッセージヘッダーフィールドやSMTPエンベロープからMAIL FROMアドレス：音声メッセージの実際の送信者は、「送信者」に指定されたものと同じではないかもしれません。しっかりと制限された環境では、十分な物理的およびソフトウェアのコントロールは、この問題の防止を確実にすることができるかもしれません。「から：」または：「送信者」また、送信者の声の認識とは無関係に指定されているの送信者の身元の信頼を提供することができます。 SMTPの実装は、メッセージの送信者の固有の認証を提供せず、また、このような認証を提供する義務の下にサイトがあることを認識すべきです。

9.2.2. Unsolicited voice mail

9.2.2. 迷惑ボイスメール

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.

ボイスメールボックスにインターネットメールアドレスを割り当てると、迷惑メッセージ（テキストやボイスメールのいずれか）を受信する可能性を開きます。伝統的に、ボイスメールシステムは、閉じた環境で動作し、未知の送信者の影響を受けませんでした。ボイスメールユーザーは、メールボックスのプライバシーの高い期待を持っているし、セキュリティ違反などのメッセージを考慮することができます。多くのインターネットメールシステムでは、この問題を抑制するための試みで未知のソースからのすべてのメッセージをブロックするように選択されています。

9.2.3. Message disclosure

9.2.3. メッセージ公開

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.

ボイスメッセージシステムのユーザは、セキュリティの強化せずにインターネットメールが提供するレベルより高いメッセージプライバシーのレベルの期待を持っています。ユーザーによるプライバシーのこの予想は、可能な限り保存されるべきです。

9.3. Security Techniques

9.3. セキュリティ技術

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.

十分な物理的およびソフトウェアの制御は制限された環境において許容可能です。さらに、この文書で指定されたプロファイルは、どのような方法で、暗号化認証するために、任意のインターネットオブジェクトまたはチャネルセキュリティプロトコルの使用を排除するものではない、またはメッセージを非否認します。

10. Normative References

10.引用規格

[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.、フリード、N.、ローズ、M.、Stefferud、E.およびD.クロッカー、 "8ビット・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]ヴォードルイユ、G.とG.パーソンズ、 "トール品質の音声 - 32キロビット/秒適応差分パルス符号変調（ADPCM）MIMEサブタイプ登録"、RFC 3802、2004年6月。

[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]ヴォードルイユ、G.、RFC 3030、2000年12月 "大規模およびバイナリMIMEメッセージの送信のためのSMTPサービス拡張"。

[CODES] Vaudreuil, G. "Enhanced Mail System Status Codes", RFC 1893, January 1996.

[CODES]ヴォードルイユ、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]ドーソン、F.、ハウズ、T.およびM.スミス、 "ディレクトリ情報のMIMEのContent-Type"、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.ドルナー、 "インターネット・メッセージでプレゼンテーション情報を伝える：のContent-Dispositionヘッダー"、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]ムーア、K.、RFC 3461 "配信状態通知（DSN）のための簡易メール転送プロトコル（SMTP）サービス拡張"、2003年1月。

[DSN] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, January 2003.

[DSN]ムーア、K.とG.ボードルイ、 "配送状態通知のための広げることができるメッセージフォーマット"、RFC 3464、2003年1月。

[DUR] Parsons, G. and G. Vaudreuil, "Content Duration MIME Header Definition", RFC 3803, June 2004.

[DUR]パーソンズ、G.とG.ボードルイ、 "満足している持続時間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.、 "簡易メール転送プロトコル"、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キロビット/秒適応差分パルス符号変調（ADPCM）。

[HOSTREQ] Braden, R., "Requirements for Internet Hosts -- Application and Support", STD 3, RFC 1123, October 1989.

[HOSTREQ]ブレーデン、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]ハンセン、T.、エド。そして、G.ボードルイ、エド。、 "メッセージ気質通知"、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]ローズ、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]解放され、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）第一部：インターネットメッセージ本体のフォーマット"、RFC 2045、1996年11月。

[MIME2] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types ", RFC 2046, November 1996.

[MIME2]解放され、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]ムーア、K.、 "多目的インターネットメール拡張（MIME）パート3：非ASCIIテキストのためのメッセージヘッダの拡張"、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]解放され、N.、Klensin、J.とJ.ポステル、 "多目的インターネットメール拡張（MIME）第四部：登録手順"、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]解放され、N.と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]フリード、N.and A.カーギル、 "コマンドパイプラインのためのSMTPサービス拡張" 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.

[REPORT]ヴォードルイユ、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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]クロッカー、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.

STD 10、RFC 1870、1995年11月 "メッセージサイズ宣言のためのSMTPサービス拡張" [SIZE] Klensin、J.、フリード、N.とK.ムーア、。

[STATUS] Freed, N., "SMTP Service Extension for Returning Enhanced Error Codes", RFC 2034, October 1996.

"強化されたエラーコードを返すためのSMTPサービス拡張" [STATUS]フリード、N.、RFC 2034、1996年10月。

[TIFF-F] Parsons, G. and J. Rafferty, "Tag Image File Format: Application F", RFC 2306, March 1998.

[TIFF-F]パーソンズ、G.とJ.・ラファティ、 "タグイメージファイル形式：アプリケーション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]パーソンズ、G.、ラファティ、J.とS. Zilles、 "タグイメージファイル形式：画像/ 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]ヴォードルイユ、G.とG.パーソンズ、 "VPIMボイスメッセージMIMEサブタイプ登録"、RFC 2423、1998年9月。

[VCARD] Dawson, F. and T. Howes, "vCard MIME Directory Profile" RFC 2426, September 1998.

[VCARD]ドーソン、F.とT.ハウズ、 "vCardのMIMEディレクトリプロフィール" 1998年9月、RFC 2426。

[VPIM1] Vaudreuil, G., "Voice Profile for Internet Mail", RFC 1911, February 1996.

[VPIM1]ヴォードルイユ、G.、 "インターネットメール用の音声プロファイル"、RFC 1911、1996年2月。

[VPIM2] Vaudreuil, G. and G. Parsons, "Voice Profile for Internet Mail, Version 2", RFC 2421, September 1998.

[VPIM2]ヴォードルイユ、G.とG.パーソンズ、 "インターネットメール、バージョン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月。

11. Acknowledgments

11.謝辞

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.

著者は電子メッセージング協会（EMA）、ボイスメッセージ委員会のメンバー、特に、およびIETF VPIMワーク・グループへの特別な感謝を提供したいと思い、VPIM仕様と努力の彼らのサポートのために、彼らは確実にするために行われてきたその成功。

12. - VPIM Requirements Summary

12 - 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

エリア - 各機能が適用される準拠面積： - コンテンツT - Cを輸送

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

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.ファックスがサポートされている場合。 8.ファックスコンテンツを提示することができない場合は、それがドロップされる可能性があります。テキスト/ディレクトリ内のvCardの9取り扱いはもはや定義されていません。

13. - Example Voice Messages

13. - 例ボイスメッセージ

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

To：+19725551212@vm1.mycompany.comへ：+16135551234@VM1.mycompany.comから： "パーソンズ、グレン" <12145551234@VM2.mycompany.com>日付：月、8月26日10時20分20秒93 -0700 （CDT）MIME-バージョン：1.0（声2.0）コンテンツ・タイプ：マルチパート/音声メッセージ。バージョン= 2.0;境界= "MessageBoundary" コンテンツ転送エンコード：7ビットのMessage-ID：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: part1@VM2-4321

--MessageBoundaryコンテンツタイプ：オーディオ/ 32KADPCMコンテンツ転送エンコード：Base64のコンテンツディスポジション：インライン;声=発信--名前音声コンテンツ言語：EN-USのContent-ID：その1 @ VM2-4321

glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd (This is a sample of the base-64 Spoken Name data) fgdhgddlkgpokpeowrit09==

glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd（これはベース64音声名データのサンプルである）fgdhgddlkgpokpeowrit09 ==

--MessageBoundary Content-type: Audio/32KADPCM Content-Transfer-Encoding: Base64 Content-Disposition: inline; voice=Spoken-Subject Content-Language: en-US Content-ID: part2@VM2-4321

--MessageBoundaryコンテンツタイプ：オーディオ/ 32KADPCMコンテンツ転送エンコード：Base64のコンテンツディスポジション：インライン;音声=音声-タイトル内容言語：EN-USのContent-ID：その2 @ VM2-4321

glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd (This is a sample of the base-64 Spoken Subject data) fgdhgddlkgpokpeowrit09==

glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd（これはベース64音声処理対象データのサンプルである）fgdhgddlkgpokpeowrit09 ==

--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

--MessageBoundaryコンテンツタイプ：オーディオ/ 32KADPCMコンテンツ転送エンコード：Base64のコンテンツの説明：ブランドXボイスメッセージのContent-処分：インライン;音声=音声メッセージ。ファイル名= msg1.726のコンテンツ再生時間：25

iIiIiIjMzN3czdze3s7d7fwfHhcvESJVe/4yEhLz8/FOQjVFRERCESL/zqrq (This is a sample of the base64 message data) zb8tFdLTQt1PXj u7wjOyRhws+krdns7Rju0t4tLF7cE0K0MxOTOnRW/Pn30c8uHi9==

iIiIiIjMzN3czdze3s7d7fwfHhcvESJVe / 4yEhLz8 / FOQjVFRERCESL / zqrq（これはBASE64メッセージデータのサンプルである）zb8tFdLTQt1PXj u7wjOyRhws + krdns7Rju0t4tLF7cE0K0MxOTOnRW / Pn30c8uHi9 ==

--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

--MessageBoundaryコンテンツタイプ：オーディオ/ 32KADPCMコンテンツ転送エンコード：Base64のコンテンツディスポジション：インライン;声=発信--名前音声コンテンツ言語：EN-USのContent-ID：その3 @ VM2-4321

glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd (This is a sample of the base-64 Spoken Name data) fgdhgd dlkgpokpeowrit09==

glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd（これはベース64音声名データのサンプルである）fgdhgdのdlkgpokpeowrit09 ==

--MessageBoundary Content-type: Audio/32KADPCM Content-Description: Forwarded Message Annotation Content-Disposition: inline; voice=Voice-Message Content-Transfer-Encoding: Base64

--MessageBoundaryコンテンツタイプ：オーディオ/ 32KADPCMコンテンツの説明：転送されたメッセージ注釈のContent-処分：インライン;音声=音声メッセージコンテンツ転送エンコード：Base64で

glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd (This is the voiced introductory remarks encoded in base64) jrgoij3o45itj09fiuvdkjgWlakgQ93ijkpokfpgokQ90gQ5tkjpokfgW dlkgpokpeowrit09==

glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd jrgoij3o45itj09fiuvdkjgWlakgQ93ijkpokfpgokQ90gQ5tkjpokfgWのdlkgpokpeowrit09（これはbase64でエンコードされた有声音前置きあり）==

--MessageBoundary Content-type: Message/RFC822 Content-Transfer-Encoding: 7bit

--MessageBoundaryコンテンツタイプ：メッセージ/ 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)

To：+19725552345@VM2.mycompany.comから： "パーソンズ、グレン、W." <+16135551234@VM1.mycompany.com>日付：月、8月26日8時23分10秒93 -0500（EST）コンテンツタイプ：マルチパート/音声メッセージ。バージョン= 2.0;境界= "MessageBoundary2" コンテンツ転送エンコード：7ビットMIME-バージョン：1.0（声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

--MessageBoundary2コンテンツタイプ：オーディオ/ 32KADPCMコンテンツ転送エンコード：Base64のコンテンツディスポジション：インライン;声=発信--名前音声コンテンツ言語：EN-USのContent-ID：その6 @ VM2-4321

glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd (This is a sample of the base-64 Spoken Name data) fgdhgd dlkgpokpeowrit09==

glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd（これはベース64音声名データのサンプルである）fgdhgdのdlkgpokpeowrit09 ==

--MessageBoundary2 Content-type: Audio/32KADPCM Content-Disposition: inline; voice=Voice-Message Content-Transfer-Encoding: Base64

--MessageBoundary2コンテンツタイプ：オーディオ/ 32KADPCMコンテンツディスポジション：インライン;音声=音声メッセージコンテンツ転送エンコード：Base64で

glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd (This is the original message audio data) fgwersdfmniwrjj jrgoij3o45itj09fiuvdkjgWlakgQ93ijkpokfpgokQ90gQ5tkjpokfgW dlkgpokpeowrit09==

glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd（これは元のメッセージの音声データである）fgwersdfmniwrjj jrgoij3o45itj09fiuvdkjgWlakgQ93ijkpokfpgokQ90gQ5tkjpokfgW dlkgpokpeowrit09 ==

--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ゲートウェイによりメッセージの送信者に送信されるDSNのためのものです。

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"

日付：木から、1994年7月7日午前17時16分05秒-0400：メール配信サブシステム<MAILER-DAEMON@vm.company.com>メッセージ-ID：<199407072116.RAA14128@vm1.company.com>件名：返された音声メッセージTo：2175552345@VM2.mycompany.com MIME-バージョン：1.0のContent-Type：マルチパート/レポート。レポートタイプ=配送状況。境界= "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コンテンツタイプ：オーディオ/ 32KADPCMコンテンツの説明：配信ステータス通知のContent-処分音声：インライン;音声=音声メッセージ通知コンテンツ転送エンコード：Base64で

glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadadffsssddasdasd (This is a voiced description of the error in base64) jrgoij3o45itj09fiuvdkjgWlakgQ93ijkpokfpgokQ90gdffkjpokfgW dlkgpokpeowrit09==

glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadadffsssddasdasd（これはBASE64でエラーの有声説明である）jrgoij3o45itj09fiuvdkjgWlakgQ93ijkpokfpgokQ90gdffkjpokfgWのdlkgpokpeowrit09 ==

--RAA14128.773615765/VM1.COMPANY.COM Content-type: Message/Delivery-Status

--RAA14128.773615765 / VM1.COMPANY.COMコンテンツタイプ：メッセージ/デリバリー-ステータス

Reporting-MTA: dns; vm1.company.com

報告-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

オリジナル・受信者：RFC822; 2145551234@VM1.mycompany.com最終受信者：RFC822; 2145551234@VM1.mycompany.com処置：失敗ステータス：5.1.1（ユーザーが存在しない）の診断-コード：SMTP; 550メールボックスの最終-試行-日付が見つからない：木、1994年7月7日夜05時15分49秒-0400

--RAA14128.773615765/VM1.COMPANY.COM content-type: Message/RFC822

--RAA14128.773615765 / VM1.COMPANY.COMコンテンツ・タイプ：メッセージ/ 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コンテンツタイプ：オーディオ/ 32KADPCMコンテンツ概要：処分通知のContent-処分音声：インライン;音声=音声メッセージ通知コンテンツ転送エンコード：Base64で

glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadadffsssddasdasd (Voiced description of the disposition action in base64) jrgoij3o45itj09fiuvdkjgWlakgQ93ijkpokfpgokQ90gdffkjpokfgW dlkgpokpeowrit09==

glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadadffsssddasdasd（BASE64で配置アクションの有声音説明）jrgoij3o45itj09fiuvdkjgWlakgQ93ijkpokfpgokQ90gdffkjpokfgW dlkgpokpeowrit09 ==

--RAA14128.773615765/EXCHANGE.COMPANY.COM Content-type: Message/Disposition-Notification

--RAA14128.773615765 / EXCHANGE.COMPANY.COMコンテンツタイプ：気質メッセージ/通知-

Reporting-UA: gregs-laptop.dallas.company.com (Unified FooMail 3.0)

報告-UA：gregs-laptop.dallas.company.com（3.0 FooMailを統一）

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

オリジナル・受信者：RFC822; 22722@vm.company.com最終受信者：RFC822; Greg.Vaudreuil@foomail.company.comオリジナル・メッセージ-ID：<199509192301.12345@vm2.mycompany.com>処分：手動アクション/ MDN -sent、自動的に。表示されました

--RAA14128.773615765/EXCHANGE.COMPANY.COM Content-type: Message/RFC822

--RAA14128.773615765 / EXCHANGE.COMPANY.COMコンテンツタイプ：メッセージ/ RFC822

[original VPIM message goes here]

[元VPIMメッセージはここに行きます]

--RAA14128.773615765/EXCHANGE.COMPANY.COM--

--RAA14128.773615765 / EXCHANGE.COMPANY.COM--

14. - Example Error Voice Processing Error Codes

14 - 例のエラー音声処理のエラーコード

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)

リモートシステムは、（ - 接続時に「C」への間違ったバージョン応答で「D」）5.5.5永久プロトコルエラーAMIS-アナログハンドシェイクを答えませんでした

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

メールボックスは、TEXT 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常設システムエラーシステムが対応プライベートではありません - 備わっていない可能

15. - Example Voice Processing Disposition Types

15. - 例音声処理処分の種類

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-送られ、自動的に。領収書が自動的に表示さ返さ

Message deleted from mailbox manual-action/MDN-sent-automatically; by user without listening deleted

メールボックスの手動アクション/-送ら-自動的にMDNから削除されたメッセージ。ユーザーによって削除聞かず

Message cleared when mailbox manual-action/MDN-sent-automatically; deleted by admin deleted/mailbox-terminated

メールボックスの手動アクション/ MDN-送られ、自動的にメッセージがクリア。削除された管理者によって削除/メールボックスが終わります

Message automatically deleted automatic-action/ when older than administrator MDN-sent-automatically; deleted/ set threshold expired

メッセージは自動的にMDN-送られ、自動的に管理者よりも古い自動アクションを/削除しました。削除/設定されたしきい値の有効期限が切れ

Message processed, however manual-action/MDN-sent-automatically; audio encoding unknown - processed/error unable to play to user Error: unknown audio encoding

メッセージ処理された、しかし、手動アクション/-送られ、自動的にMDN;オーディオエンコーディング不明 - ユーザーエラーに再生できない/エラー処理された：不明なオーディオエンコーディング

16. - IANA Registrations

16. - IANA登録

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文書で定義された音声コンテンツの配置パラメータの[DISP]あたりの登録への変更、RFC 2421.は存在しない[MIME4】マルチパート/ボイスメッセージのコンテンツタイプがで定義のあたりの登録の変更はありません以前のVPIM v2のドキュメント、RFC 2423。

Both are presented here for information.

どちらも、情報のためにここに提示されています。

16.1. Voice Content-Disposition Parameter Definition

16.1. 音声コンテンツディスポジションパラメータ定義

To: IANA@IANA.ORG

と：いあな＠いあな。おＲＧ

Subject: Registration of new Content-Disposition parameter

件名：新しいコンテンツ処分パラメータの登録

Content-Disposition parameter name: voice

Content-Dispositionパラメータ名：声

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

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つのインスタンスが存在すべきであることに留意されたいです。所与のタイプ（すなわち、パラメータ値）の追加の例は、添付の転送ボイスメッセージ内で起こり得ます。

16.2. Multipart/Voice-Message MIME Media Type Definition

16.2. マルチパート/音声メッセージのMIMEメディアタイプの定義

To: ietf-types@iana.org Subject: Registration of MIME media type Multipart/voice-message

To：ietf-types@iana.org件名：MIMEメディアタイプマルチパート/音声メッセージの登録

MIME media type name: multipart

MIMEメディアタイプ名：マルチパート

MIME subtype name: voice-message

MIMEサブタイプ名：音声メッセージ

Required parameters: boundary, version

必須パラメータ：境界、バージョン

The use of boundary is defined in [MIME2]

境界の使用は、[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].

値「2.0」が含まれているバージョンパラメータ囲まれたコンテンツは、[VPIM2R2]に準拠している場合。このパラメータが存在しない場合は、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

マジックナンバー（S）：なしファイルの拡張子（S）：.VPMマッキントッシュファイルタイプコード（S）：VPIM

Person & email address to contact for further information:

詳細のために連絡する人とEメールアドレス：

Glenn W. Parsons gparsons@nortelnetworks.com

グレンW.パーソンズgparsons@nortelnetworks.com

Gregory M. Vaudreuil gregv@ieee.org

グレゴリーM.ヴォードルイユgregv@ieee.org

Intended usage: COMMON

意図している用法：COMMON

Author/Change controller:

著者/変更コントローラ：

Glenn W. Parsons & Gregory M. Vaudreuil

グレンW.パーソンズ＆グレゴリーM.ヴォードルイユ

17. - Change History: (VPIM V2) to this Document

17. - 変更履歴：（VPIM V2）は、このドキュメントに

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でそれらを揃えるために、感度の要件を作り直しました。 MIXER文書の際に排除さ依存性。

- 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（マルチパート/ボイスメッセージ）からのテキストで合流

3. Transport

3.交通

- None

- 無し

4. Conformance

4.適合性

- Aligned the table of Appendix A to the requirements in the text.

- テキスト内の要件への付録Aの表を整列。

18. Authors' Addresses

18.著者のアドレス

Gregory M. Vaudreuil Lucent Technologies 7291 Williamson Rd Dallas, TX 75214 United States

グレゴリーM.ヴォードルイユルーセント・テクノロジーズ7291のウィリアムソンRdのダラス、TX 75214米国

EMail: gregv@ieee.org

メールアドレス：gregv@ieee.org

Glenn W. Parsons Nortel Networks P.O. Box 3511, Station C Ottawa, ON K1Y 4H7 Canada

グレンW.パーソンズNortel Networksの私書箱K1Y 4H7カナダのボックス3511、駅のCオタワ、

Phone: +1-613-763-7582 Fax: +1-613-763-2697 EMail: GParsons@NortelNetworks.com

電話：+ 1-613-763-7582ファックス：+ 1-613-763-2697 Eメール：GParsons@NortelNetworks.com

19. Full Copyright Statement

19.完全な著作権声明

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）インターネット協会（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.

この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。

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.

IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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 Editor機能のための基金は現在、インターネット協会によって提供されます。

RFC 3801 - Voice Profile for Internet Mail - version 2 (VPIMv2) 日本語訳

1. Introduction

1. はじめに

1.1. Voice Messaging System Limitations

1.1. ボイスメッセージシステムの制限

1.2. Design Goals

1.2. 設計目標

1.3. Applicability for VPIM

1.3. VPIMのための適用性

2. Requirements Language

2.必要な言語

3. Protocol Restrictions

3.プロトコルの制限

4. Voice Message Interchange Format

4.ボイスメッセージ交換フォーマット

4.1. VPIM Message Addressing Formats

4.1. フォーマットへの対応VPIMメッセージ

4.1.1. VPIM Addresses

4.1.1. VPIMアドレス

4.1.2. Special Addresses

4.1.2. 特殊アドレス

4.1.3. Distribution Lists

4.1.3. 配布リスト

4.2. Message Header Fields

4.2. メッセージヘッダフィールド

4.2.1. From

4.2.1. から

4.2.2. To

４。２。２。 と

4.2.3. Cc

4.2.3. CC

4.2.4. Date

4.2.4. 日付

4.2.5. Sender

4.2.5. 送信者

4.2.6. Return-Path

4.2.6. 復路

4.2.7. Message-id

4.2.7. メッセージID

4.2.8. Reply-To

4.2.8. に返信

4.2.9. Received

4.2.9. 受け

4.2.10. MIME Version

4.2.10. MIMEバージョン

4.2.11. Content-Type

4.2.11. コンテンツタイプ

4.2.12. Content-Transfer-Encoding

4.2.12. コンテンツ転送エンコード

4.2.13. Sensitivity

4.2.13. 感度

4.2.14. Importance

4.2.14. 重要性

4.2.15. Subject

4.2.15. 主題

4.3. MIME Audio Content Descriptions

4.3. MIMEオーディオコンテンツの説明

4.3.1. Content-Description

4.3.1. コンテンツの説明

4.3.2. Content-Disposition

4.3.2. コンテンツ処分

4.3.3. Content-Duration

4.3.3. コンテンツ持続時間

4.3.4. Content-Language:

4.3.4. コンテンツ言語：

4.4. Voice Message Content Types

4.4. ボイスメッセージのコンテンツタイプ

4.4.1. Multipart/Voice-Message

4.4.1. マルチパート/音声メッセージ

4.4.2. Message/RFC822

4.4.2. メッセージ/ RFC822

4.4.3. Audio/32KADPCM

4.4.3. オーディオ/ 32KADPCM

4.4.4. Image/TIFF

4.4.4. 画像/ TIFF

4.5. Other MIME Contents

4.5. その他のMIME内容

4.5.1. Multipart/Mixed

4.5.1. ミックス/マルチパート

4.5.2. Text/Directory

４。２。２。と