[要約] RFC 2421は、インターネットメールのための音声プロファイルのバージョン2を定義しています。このRFCの目的は、電子メールに音声メッセージを統合するための標準を提供することです。
Network Working Group G. Vaudreuil
Request for Comments: 2421 Lucent Technologies
Obsoletes: 1911 G. Parsons
Category: Standards Track Northern Telecom
September 1998
Voice Profile for Internet Mail - version 2
インターネットメールのボイスプロファイル-バージョン2
Status of this Memo
本文書の状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
Overview
概観
This document profiles Internet mail for voice messaging. It obsoletes RFC 1911 which describes version 1 of the profile. A list of changes from that document are noted in Appendix F. As well, Appendix A summarizes the protocol profiles of this version of VPIM.
このドキュメントでは、ボイスメッセージング用のインターネットメールについて説明します。プロファイルのバージョン1を記述するRFC 1911は廃止されました。そのドキュメントからの変更点のリストは、付録Fに記載されています。同様に、付録Aは、このバージョンのVPIMのプロトコルプロファイルを要約しています。
Please send comments on this document to the EMA VPIM Work Group
mailing list: <vpim-l@ema.org>
Working Group Summary
ワーキンググループの概要
This profile is not the product of an IETF working group, though several have reviewed the document. It is instead the product of the VPIM Work Group of the Electronic Messaging Association (EMA). This work group, which has representatives from most major voice mail vendors and several email vendors, has held several interoperability demonstrations between voice messaging vendors and is currently promoting VPIM trials and deployment.
このプロファイルはIETFワーキンググループの製品ではありませんが、いくつかのドキュメントをレビューしています。代わりに、Electronic Messaging Association（EMA）のVPIM Work Groupの製品です。このワークグループは、ほとんどの主要なボイスメールベンダーといくつかの電子メールベンダーからの代表者で構成されており、ボイスメッセージングベンダー間の相互運用性のデモをいくつか開催しており、現在VPIMの試用と展開を推進しています。
Table of Contents
目次
1. ABSTRACT .........................................................3
2. SCOPE ............................................................3
2.1 Voice Messaging System Limitations ............................3
2.2 Design Goals ..................................................4
3. PROTOCOL RESTRICTIONS ............................................5
4. VOICE MESSAGE INTERCHANGE FORMAT .................................6
4.1 Message Addressing Formats ....................................6
4.2 Message Header Fields .........................................9
4.3 Voice Message Content Types ..................................15
4.4 Other Message Content Types ..................................21
4.5 Forwarded Messages ...........................................23
4.6 Reply Messages ...............................................23
4.7 Notification Messages ........................................24
5. MESSAGE TRANSPORT PROTOCOL ......................................24
5.1 ESMTP Commands ...............................................25
5.2 ESMTP Keywords ...............................................27
5.3 ESMTP Parameters - MAIL FROM .................................28
5.4 ESMTP Parameters - RCPT TO ...................................29
5.5 ESMTP - SMTP Downgrading .....................................29
6. DIRECTORY ADDRESS RESOLUTION ....................................30
7. IMAP ............................................................30
8. MANAGEMENT PROTOCOLS ............................................30
8.1 Network Management ...........................................31
9. CONFORMANCE REQUIREMENTS ........................................31
10. SECURITY CONSIDERATIONS ........................................32
10.1 General Directive ...........................................32
10.2 Threats and Problems ........................................32
10.3 Security Techniques .........................................33
11. REFERENCES .....................................................33
12. ACKNOWLEDGMENTS ................................................36
13. AUTHORS' ADDRESSES .............................................36
14. APPENDIX A - VPIM REQUIREMENTS SUMMARY .........................37
15. APPENDIX B - EXAMPLE VOICE MESSAGES ............................45
16. APPENDIX C - EXAMPLE ERROR VOICE PROCESSING ERROR CODES ........50
17. APPENDIX D - EXAMPLE VOICE PROCESSING DISPOSITION TYPES ........51
18. APPENDIX E - IANA REGISTRATIONS ................................52
18.1 vCard EMAIL Type Definition for VPIM ........................52
18.2 Voice Content-Disposition Parameter Definition ..............52
19. APPENDIX F - CHANGE HISTORY: RFC 1911 TO THIS DOCUMENT .........54
20. FULL COPYRIGHT NOTICE ..........................................56
A class of special-purpose computers has evolved to provide voice messaging services. These machines generally interface to a telephone switch and provide call answering and voice messaging services. Traditionally, messages sent to a non-local machine are transported using analog networking protocols based on DTMF signaling and analog voice playback. As the demand for networking increases, there is a need for a standard high-quality digital protocol to connect these machines. The following document is a profile of the Internet standard MIME and ESMTP protocols for use as a digital voice messaging networking protocol. The profile is referred to as VPIM (Voice Profile for Internet Mail) in this document.
ボイスメッセージングサービスを提供するために、専用コンピュータのクラスが進化しました。これらのマシンは通常、電話交換機に接続し、通話応答およびボイスメッセージサービスを提供します。従来、非ローカルマシンに送信されたメッセージは、DTMFシグナリングとアナログ音声再生に基づくアナログネットワークプロトコルを使用して転送されます。ネットワークの需要が高まるにつれ、これらのマシンを接続するための標準的な高品質デジタルプロトコルが必要になります。次のドキュメントは、デジタルボイスメッセージングネットワーキングプロトコルとして使用するためのインターネット標準MIMEおよびESMTPプロトコルのプロファイルです。このドキュメントでは、このプロファイルをVPIM（Voice Profile for Internet Mail）と呼びます。
This profile is based on earlier work in the Audio Message Interchange Specification (AMIS) group that defined a voice messaging protocol based on X.400 technology. This profile is intended to satisfy the user requirements statement from that earlier work with the industry standard ESMTP/MIME mail protocol infrastructures already used within corporate intranets. This second version of VPIM is based on implementation experience and obsoletes RFC 1911 which describes version 1 of the profile.
このプロファイルは、X.400テクノロジーに基づくボイスメッセージングプロトコルを定義したAudio Message Interchange Specification（AMIS）グループの以前の作業に基づいています。このプロファイルは、企業イントラネット内ですでに使用されている業界標準のESMTP / MIMEメールプロトコルインフラストラクチャでの以前の作業からのユーザー要件ステートメントを満たすことを目的としています。このVPIMの2番目のバージョンは、実装経験に基づいており、プロファイルのバージョン1について説明しているRFC 1911を廃止しています。
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は、インターネットの多目的マルチメディアメッセージング標準です。このドキュメントは、その機能を明確に認識し、さまざまなメッセージングテクノロジー、主に音声とファクシミリを交換するためのメカニズムを提供します。
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 compliant systems.
このドキュメントでは、音声処理サーバープラットフォーム間で使用するインターネットマルチメディアメッセージングプロトコルの制限付きプロファイルを指定します。これらのプラットフォームは、歴史的に特殊用途のコンピューターであり、従来のインターネット電子メール対応コンピューターに通常関連付けられているのと同じ機能を備えていないことがよくあります。その結果、VPIMは必要に応じて追加機能も指定します。このプロファイルは、準拠システム間の相互作用を可能にする最小限の共通機能セットを指定することを目的としています。
The following are typical limitations of voice messaging platform which 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 no relaying of messages, and RFC 822 header fields may have limited use in the context of the limited messaging features currently deployed.
2）ボイスメールマシンは通常、統合されたメッセージ転送エージェント、メッセージストア、およびユーザーエージェントとして機能します。メッセージのリレーはなく、RFC 822ヘッダーフィールドは、現在展開されている制限されたメッセージング機能のコンテキストで使用が制限される場合があります。
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）ボイスメールメッセージストアは、通常、インターネットメッセージの完全なセマンティクスを保持できません。そのため、ゲートウェイ処理にボイスメールマシンを使用することはサポートされていません。特に、受信者リスト、「Received」行、および「Message-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 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 is 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 which do not understand MIME, though typical use is expected to be within corporate intranets. 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 compliant messages, some may be required to originate compliant structures.
このプロファイルは、MIMEを理解しないインストールベースゲートウェイを備えたグローバルインターネットなどの環境で使用できるほど堅牢であることを目的としていますが、通常の使用は企業のイントラネット内で行われると予想されます。信頼できるエラーメッセージやバイナリトランスポートなどの完全な機能を使用するには、VPIM転送エージェントとして使用するゲートウェイ（MXレコードなど）を慎重に選択する必要があります。このドキュメントでは、VPIMメッセージの読み取りと作成に汎用MIME電子メールパッケージを使用することを排除していません。 VPIM準拠メッセージを受信するために特別な設定は必要ありませんが、準拠構造を発信するために必要なものもあります。
It is expected that a VPIM messaging system will be managed by a system administrator who can perform TCP/IP network configuration. 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.
VPIMメッセージングシステムは、TCP / IPネットワーク構成を実行できるシステム管理者によって管理されることが期待されています。ファクシミリまたは複数の音声エンコーディングを使用する場合、システム管理者がネットワーク化されたメールマシンの機能のリストを維持して、機能サポートの不足による配信不能メッセージの送信を減らすことをお勧めします。これらのディレクトリ一覧機能の構成、実装、および管理は、ローカルな問題です。
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.
このプロトコルは、メッセージごとの受信者数を制限しません。可能な場合、サーバーの実装では、1つのメッセージの受信者数を制限しないでください。無制限の受信者をサポートする実装はなく、サポートされる受信者の数は非常に少ない場合があることが認識されています。
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 the RFC 1425 SMTP service extensions to declare the maximum message size supported.
このプロトコルは最大メッセージ長を制限しません。実装者は、一部のマシンでは過度に長いメッセージを受け入れることができないことを理解する必要があります。 RFC 1425 SMTPサービス拡張では、サポートされる最大メッセージサイズを宣言するメカニズムが定義されています。
The message size indicated in the ESMTP SIZE parameter is in bytes, not minutes or seconds. The number of bytes varies by voice encoding format and includes the MIME wrapper overhead. If the length must be known before sending, an approximate translation into minutes or seconds can be performed if the voice encoding is known.
ESMTP SIZEパラメータで示されるメッセージサイズは、分や秒ではなくバイト単位です。バイト数は音声エンコード形式によって異なり、MIMEラッパーのオーバーヘッドが含まれます。送信前に長さがわかっている必要がある場合、音声エンコーディングがわかっていれば、分または秒におよそ変換できます。
The following sections describe the restrictions and additions to Internet mail protocols that are required to be compliant 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. It is also advisable to check for IETF drafts of various Internet Mail specifications that are later than the most recent RFCs since, for example, MIME has yet to be published as a full IETF Standard. The table in Appendix A summarizes the protocol details of this profile.
次のセクションでは、このVPIM v2プロファイルに準拠するために必要なインターネットメールプロトコルの制限と追加について説明します。ここでは、SMTP、ESMTP、MIMEのさまざまな機能について説明しますが、詳細については、関連するRFCを参照してください。たとえば、MIMEはまだ完全なIETF標準として公開されていないため、最新のRFCより後のさまざまなインターネットメール仕様のIETFドラフトを確認することもお勧めします。付録Aの表は、このプロファイルのプロトコルの詳細をまとめたものです。
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」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [REQ]で説明されているように解釈されます。
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 [MIME], the X.400 gateway specification [X.400], delivery status and message disposition notifications [REPORT][DSN][DRPT][STATUS][MDN], and the electronic business card [MIMEDIR][VCARD].
ボイスメッセージ交換フォーマットは、インターネットメールプロトコルスイートのプロファイルです。このセクションで定義された形式を含むインターネットメールメッセージは、このドキュメントではVPIMメッセージと呼ばれます。その結果、このドキュメントは、インターネットメールの仕様を理解していることを前提としています。具体的には、VPIMはインターネットメッセージのメッセージフォーマット標準[RFC822]、多目的インターネットメッセージ拡張[MIME]、X.400ゲートウェイ仕様[X.400]、配信ステータスとメッセージ処理通知[レポート] [DSN]のコンポーネントを参照します。 [DRPT] [ステータス] [MDN]、および電子名刺[MIMEDIR] [VCARD]。
RFC 822 addresses are 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.
RFC 822アドレスは、ドメインネームシステムに基づいています。このネーミングシステムには2つのコンポーネントがあります。ユーザー名またはメールボックスの識別に使用されるローカル部分です。グローバルマシンの識別に使用されるホスト部分。
The local part of the address shall be a US-ASCII string uniquely identifying a mailbox on a destination system. For voice messaging, the local part is a printable string containing the mailbox ID of the originator or recipient. While alpha characters and long mailbox identifiers are permitted, 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 un-replyable. 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).
アドレスのローカル部分は、宛先システムのメールボックスを一意に識別するUS-ASCII文字列である必要があります。ボイスメッセージの場合、ローカル部分は、発信者または受信者のメールボックスIDを含む印刷可能な文字列です。アルファベット文字と長いメールボックス識別子が許可されていますが、ほとんどのボイスメールネットワークは、数値のメールボックス識別子に依存して、制限された10桁の電話のキーパッドとの互換性を維持しています。その結果、一部のボイスメッセージシステムは、ローカルの数値部分しか処理できない場合があります。これらのシステムで英数字のローカル部分を受信すると、アドレスがローカルで一意の（ただし、受信者を混乱させる）番号にマッピングされるか、最悪の場合、アドレスが削除されてメッセージが返信できなくなる可能性があります。さらに、これらのシステムでは、複雑なキーシーケンスやなんらかの形式のディレクトリルックアップを使用せずに、英数字のローカルパーツでメッセージを作成することが難しい場合があります（6を参照）。
The use of the domain naming 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).
ドメインネーミングシステムの使用は、ユーザーに対して透過的である必要があります。ユーザーが入力したアドレスに基づいて完全修飾ドメイン名（FQDN）を検索するのは、ボイスメールマシンの責任です（6を参照）。
In the absence of a global directory, specification of the local part is expected to conform to international or private telephone numbering plans. It is likely that private numbering plans will prevail and these are left for local definition. However, it is RECOMMENDED that public telephone numbers be noted according to the international numbering plan described in [E.164]. The indication that the local part is a public telephone number is given by a preceding `+' (the `+' would not be entered from a telephone keypad, it is added by the system as a flag). Since the primary information in the numeric scheme is contained by the digits, other character separators (e.g. `-') may be ignored (i.e. to allow parsing of the numeric local mailbox) or may be used to recognize distinct portions of the telephone number (e.g. country code). The specification of the local part of a VPIM address can be split into the four groups described below:
グローバルディレクトリがない場合、ローカルパーツの仕様は、国際またはプライベートの電話番号計画に準拠することが期待されます。プライベート番号計画が普及する可能性が高く、これらは地域の定義に任されています。ただし、[E.164]に記載されている国際番号計画に従って、公衆電話番号に注意することをお勧めします。ローカル部分が公衆電話番号であるという表示は、先行する「+」によって与えられます（「+」は電話のキーパッドから入力されないため、システムによってフラグとして追加されます）。数値スキームの主要な情報は数字に含まれているため、他の文字セパレーター（たとえば、「-」）は無視される（つまり、数値のローカルメールボックスの解析を可能にする）か、電話番号の異なる部分を認識するために使用されます（たとえば国コード）。 VPIMアドレスのローカル部分の仕様は、以下で説明する4つのグループに分けることができます。
1) mailbox number - for use as a private numbering plan (any number of digits) - e.g. 2722@lucent.com
1）メールボックス番号-プライベート番号計画（任意の桁数）として使用-たとえば2722@lucent.com
2) mailbox number+extension
- for use as a private numbering plan with extensions
any number of digits, use of `+' as separator
- e.g. 2722+111@Lucent.com
3) +international number - for international telephone numbers conforming to E.164 maximum of 15 digits - e.g. +16137637582@vm.nortel.ca
3）+国際番号-E.164最大15桁に準拠する国際電話番号の場合-例+16137637582@vm.nortel.ca
4) - 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）-最大15桁の内線（たとえば、PBXの背後）を備えた、最大15桁のE.164に準拠する国際電話番号の場合。 -例+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.
このアドレス形式は、ボイスメッセージング業界での現在の使用法と互換性があるように設計されていることに注意してください。 RFC 2303-2304のアドレッシング形式とは互換性がありません。テレフォニーサービスがインターネット上でより広く普及するにつれて、これらのアドレス形式が収束することが予想されます。
Special addresses are provided for compatibility with the conventions of Internet mail. These addresses do not use numeric local addresses, both to conform to current Internet practice and to avoid conflict with existing numeric addressing plans. Two special addresses are RESERVED for use as follows:
インターネットメールの規則との互換性のために、特別なアドレスが提供されています。これらのアドレスは、数値のローカルアドレスを使用しません。これは、現在のインターネットの慣行に準拠するためと、既存の数値のアドレス指定計画との競合を避けるためです。 2つの特別なアドレスは、次のように使用するために予約されています。
postmaster@domain
postmaster @ domain
By convention, a special mailbox named "postmaster" MUST exist on all systems. This address is used for diagnostics and should be checked regularly by the system manager. This mailbox is particularly likely to receive text messages, which is not normal on a voice processing platform. The specific handling of these messages is an individual implementation choice.
慣例により、「postmaster」という名前の特別なメールボックスがすべてのシステムに存在しなければなりません。このアドレスは診断に使用され、システム管理者が定期的に確認する必要があります。このメールボックスはテキストメッセージを受信する可能性が高く、これは音声処理プラットフォームでは通常ではありません。これらのメッセージの特定の処理は、個々の実装の選択です。
non-mail-user@domain
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" must 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. For compatibility with the installed base of mail user agents, implementations that generate this special address MUST send a negative delivery status notification (DSN) for reply messages sent to the undeliverable address. The status code for such NDN's is 5.1.1 "Mailbox does not exist".
電話応答メッセージなどのメッセージへの返信が不可能な場合は、特別なアドレス「非メールユーザー」を発信者のアドレスとして使用する必要があります。 「電話応対」などのテキスト名、または電話番号がある場合はそれを使用できます。この特別なアドレスは、到達できない発信者を示すトークンとして使用されます。メールユーザーエージェントのインストールベースとの互換性のために、この特別なアドレスを生成する実装は、配信不能アドレスに送信された返信メッセージに対して否定配信ステータス通知（DSN）を送信する必要があります。このようなNDNのステータスコードは5.1.1「メールボックスが存在しません」です。
Example:
例：
From: Telephone Answering <non-mail-user@mycompany.com>
There are many ways to handle distribution list (DL) expansions and none are 'standard'. Simple alias is a behavior closest to what most voice mail systems do today and what is to be used with VPIM messages. That is:
配布リスト（DL）の展開を処理するには多くの方法があり、どれも「標準」ではありません。シンプルエイリアスは、ほとんどのボイスメールシステムが現在行っていること、およびVPIMメッセージで使用されることに最も近い動作です。あれは：
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 and the Return-Path: RFC 822 field)
発信者への返信-（RFC822 Reply-toまたはFromフィールドのアドレス）送信者へのエラー-（ESMTP交換のMAIL FROM：フィールドのアドレスとReturn-Path：RFC 822フィールド）
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 (e.g. unknown DL expansion) then the recipient header fields MUST be omitted to indicate that an accurate list of recipients (e.g. for use with a reply-all capability) is not known.
一部の専用ボイスメッセージングプロトコルには、エンベロープ内の特定のコピーの受信者のみが含まれ、日付とメッセージごとの機能を除いて「ヘッダーフィールド」が含まれていません。ほとんどのボイスメッセージシステムは、メッセージキューに「ヘッダー情報」を提供せず、配信情報のみを含みます。その結果、受信者情報はToまたはCCヘッダーフィールドのいずれかにある場合があります。すべての受信者を提示できない場合（不明なDL拡張など）、受信者の正確なリスト（たとえば、全返信機能で使用するため）が不明であることを示すために、受信者ヘッダーフィールドを省略しなければなりません（MUST）。
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 voice messages:
次のヘッダー行は、VPIMボイスメッセージでの使用が許可されています。
The originator's fully-qualified domain address (a mailbox address followed by the fully-qualified domain name). The user listed in this field should be presented in the voice message envelope as the originator of the message.
発信者の完全修飾ドメインアドレス（メールボックスアドレスとそれに続く完全修飾ドメイン名）。このフィールドにリストされているユーザーは、メッセージの発信者としてボイスメッセージエンベロープに表示されます。
Systems compliant 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]
このプロファイルに準拠するシステムは、名前が利用可能な場合、引用符で囲まれた音声メッセージの発信者のテキスト個人名を提供する必要があります（SHOULD）。企業メールボックスまたは定位置メールボックスのテキスト名は、単純な文字列として提供される場合があります。 [RFC822]から
Example:
例：
From: "Joe S. User" <12145551212@mycompany.com>
From: Technical Support <611@serviceprovider.com>
The From address SHOULD be used for replies (see 4.6). However, if the From address contains <non-mail-user@domain>, the user SHOULD NOT be offered the option to reply, nor should notifications be sent to this address.
差出人アドレスは返信に使用する必要があります（4.6を参照）。ただし、差出人アドレスに<non-mail-user @ domain>が含まれている場合、ユーザーには返信するオプションを提供しないでください。
Voice mail machines may not be able to support separate attributes for the FROM, REPLY-TO, and SENDER header field and the SMTP MAIL FROM command, VPIM conforming systems SHOULD set these values to the same address. Use of addresses different than those present in the From header field address may result in unanticipated behavior.
ボイスメールマシンは、FROM、REPLY-TO、およびSENDERヘッダーフィールドとSMTP MAIL FROMコマンドの個別の属性をサポートできない場合があり、VPIM準拠システムはこれらの値を同じアドレスに設定する必要があります（SHOULD）。 Fromヘッダーフィールドのアドレスとは異なるアドレスを使用すると、予期しない動作が発生する可能性があります。
The To header contains the recipient's fully-qualified domain address. There may be one or more To: fields in any message.
Toヘッダーには、受信者の完全修飾ドメインアドレスが含まれています。メッセージには1つ以上のTo：フィールドが含まれる場合があります。
Example:
例：
To: +12145551213@mycompany.com
Systems compliant to this profile SHOULD provide a list of recipients only if all recipients are provided. The To header MUST NOT be included in the message if the sending message transport agent (MTA) cannot resolve all the addresses in it, e.g. if an address is a DL alias for which the expansion is unknown (see 4.1.3). If present, the addresses in the To header MAY be used for a reply message to all recipients.
このプロファイルに準拠するシステムは、すべての受信者が提供されている場合にのみ、受信者のリストを提供する必要があります（SHOULD）。送信メッセージトランスポートエージェント（MTA）がその中のすべてのアドレスを解決できない場合、Toヘッダーをメッセージに含めることはできません（MUST NOT）。アドレスが展開が不明なDLエイリアスの場合（4.1.3を参照）存在する場合、Toヘッダー内のアドレスは、すべての受信者への返信メッセージに使用される場合があります。
Systems compliant to this profile MAY also discard the To addresses of incoming messages because of the inability to store the information. This would, of course, make a reply-to-all capability impossible.
このプロファイルに準拠するシステムは、情報を保存できないため、着信メッセージの宛先アドレスも破棄する場合があります。もちろん、これは全員への返信機能を不可能にします。
The cc header 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 recipients.
ccヘッダーには、追加の受信者の完全修飾ドメインアドレスが含まれています。多くのボイスメールシステムは、メッセージ配信のための十分なエンベロープ情報のみを維持し、受信者の完全なリストを格納または提供することができません。
Systems compliant to this profile SHOULD provide a list of recipients only if all disclosed recipients can be provided. The list of disclosed recipients does not include those sent via a blind copy. If not, systems SHOULD omit the To and Cc header fields to indicate that the full list of recipients is unknown.
このプロファイルに準拠するシステムは、開示されたすべての受信者を提供できる場合にのみ、受信者のリストを提供する必要があります（SHOULD）。開示された受信者のリストには、ブラインドコピーを介して送信された受信者は含まれません。そうでない場合、システムはToおよびCcヘッダーフィールドを省略して、受信者の完全なリストが不明であることを示す必要があります。
Example:
例：
Cc: +12145551213@mycompany.com
Systems compliant to this profile MAY discard the Cc addresses of incoming messages as necessary. If a list of Cc or to addresses is present, these addresses MAY be used for a reply message to all recipients.
このプロファイルに準拠するシステムは、必要に応じて着信メッセージのCcアドレスを破棄してもよい（MAY）。 Ccまたはtoアドレスのリストが存在する場合、これらのアドレスはすべての受信者への返信メッセージに使用される場合があります。
The Date header contains the date, time, and time zone in which the message was sent by the originator. The time zone 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., "-0900 (PDT)". Compliant implementations SHOULD be able to convert RFC 822 date and time stamps into local time.
Dateヘッダーには、発信者がメッセージを送信した日付、時刻、およびタイムゾーンが含まれます。タイムゾーンは、4桁のタイムゾーンオフセットで表す必要があります（たとえば、北アメリカ東部標準時の-0500）。これは、括弧内のタイムゾーン名で補足できます（例： "-0900（PDT）"）。準拠した実装は、RFC 822の日付と時刻のスタンプを現地時間に変換できる必要があります（SHOULD）。
Example:
例：
Date: Wed, 28 Jul 96 10:08:49 -0800 (PST)
The sending system MUST report the time the message was sent. If the VPIM sender is relaying a message from a system which does not provide a time stamp, the time of arrival at the VPIM system SHOULD be used as the date. From [RFC822]
送信システムはメッセージが送信された時間を報告しなければなりません（MUST）。 VPIM送信者がタイムスタンプを提供しないシステムからのメッセージをリレーしている場合、VPIMシステムへの到着時刻を日付として使用する必要があります（SHOULD）。 [RFC822]から
The Sender header field contains the actual address of the originator if the message is sent by an agent on behalf of the author indicated in the From: field. This header field MAY be sent by VPIM conforming system. If it is present in a VPIM message, the receiving VPIM implementation may ignore the field and only present the From header field.
From：フィールドで指定された作成者に代わってエージェントがメッセージを送信した場合、Senderヘッダーフィールドには発信者の実際のアドレスが含まれます。このヘッダーフィールドは、VPIM準拠システムによって送信される場合があります。 VPIMメッセージに存在する場合、受信側のVPIM実装はフィールドを無視し、Fromヘッダーフィールドのみを表示する場合があります。
The Return-path header is added by the final delivering SMTP server. If present, it contains the address from the MAIL FROM parameter of the ESMTP exchange (see 5.1.2). Any error messages resulting from the delivery failure MUST be sent to this address (see [DRPT] for additional details). Note that if the Return-path is null ("<>"), e.g. no path, loop prevention or confidential, a notification MUST NOT be sent. If the Return path address is not available (either from this header or the MAIL FROM parameter) the From address may be used to deliver notifications.
Return-pathヘッダーは、最終的な配信SMTPサーバーによって追加されます。存在する場合は、ESMTP交換のMAIL FROMパラメータからのアドレスが含まれます（5.1.2を参照）。配信の失敗から生じるエラーメッセージは、このアドレスに送信する必要があります（詳細については、[DRPT]を参照してください）。 Return-pathがnull（ "<>"）の場合、パス、ループ防止、機密情報がない場合、通知を送信してはなりません（MUST NOT）。 （このヘッダーまたはMAIL FROMパラメータから）リターンパスアドレスが使用できない場合、Fromアドレスを使用して通知を配信できます。
The Message-id header contains a unique per-message identifier. A unique message-id MUST be generated for each message sent from a compliant implementation.
Message-idヘッダーには、メッセージごとの一意の識別子が含まれています。準拠した実装から送信されるメッセージごとに、一意のメッセージIDを生成する必要があります。
The message-id is not required to be stored on the receiving system. This identifier MAY be used for tracking, auditing, and returning receipt notification reports. From [RFC822]
message-idは、受信システムに保存する必要はありません。この識別子は、追跡、監査、および受信通知レポートの返信に使用できます。 [RFC822]から
Example:
例：
Message-id: <12345678@mycompany.com>
If present, the reply-to header provides a preferred address to which reply messages should be sent (see 4.6). Typically, voice mail systems can only support one originator of a message so it is unlikely that this field can be supported. A compliant system SHOULD NOT send a Reply-To header. However, if a reply-to header is present, a reply-to sender message MAY be sent to the address specified (that is, overwriting From). From [RFC822] This preferred address of the originator must also be provided in the originator's vCard EMAIL attribute, if present (see 4.3.3).
存在する場合、返信先ヘッダーは、返信メッセージの送信先となる優先アドレスを提供します（4.6を参照）。通常、ボイスメールシステムはメッセージの発信者を1つだけサポートできるため、このフィールドをサポートできる可能性は低いです。準拠システムは、Reply-Toヘッダーを送信してはならない（SHOULD NOT）。ただし、返信先ヘッダーが存在する場合、返信先送信者メッセージは指定されたアドレスに送信される場合があります（つまり、Fromが上書きされます）。 From [RFC822]発信者のこの優先アドレスは、発信者のvCard EMAIL属性（存在する場合）にも指定する必要があります（4.3.3を参照）。
The Received header contains trace information added to the beginning of a RFC 822 message by MTAs. This is the only header permitted to be added by an MTA. Information in this header is useful for debugging when using an US-ASCII message reader or a header parsing tool.
Receivedヘッダーには、MTAによってRFC 822メッセージの先頭に追加されたトレース情報が含まれています。これは、MTAによって追加が許可されている唯一のヘッダーです。このヘッダーの情報は、US-ASCIIメッセージリーダーまたはヘッダー解析ツールを使用する場合のデバッグに役立ちます。
A compliant system MUST add Received header fields when acting as a gateway and MUST NOT remove any Received fields when relaying messages to other MTAs or gateways.. These header fields MAY be ignored or deleted when the message is received at the final destination. From [RFC822]
準拠システムは、ゲートウェイとして機能する場合は受信ヘッダーフィールドを追加する必要があり、他のMTAまたはゲートウェイにメッセージをリレーする場合は受信フィールドを削除してはなりません。これらのヘッダーフィールドは、メッセージが最終宛先で受信されるときに無視または削除される場合があります。 [RFC822]から
The MIME-Version header indicates that the message conforms to the MIME message format specification. Systems compliant with this specification SHOULD include a comment with the words "(Voice 2.0)". RFC 1911 defines an earlier version of this profile and uses the token (Voice 1.0). From [MIME1][VPIM1]
MIME-Versionヘッダーは、メッセージがMIMEメッセージ形式の仕様に準拠していることを示します。この仕様に準拠するシステムには、「（Voice 2.0）」という単語を含むコメントを含める必要があります（SHOULD）。 RFC 1911は、このプロファイルの以前のバージョンを定義し、トークン（Voice 1.0）を使用しています。 [MIME1] [VPIM1]から
Example:
例：
MIME-Version: 1.0 (Voice 2.0)
MIMEバージョン：1.0（Voice 2.0）
This identifier is intended for information only and SHOULD NOT be used to semantically identify the message as being a VPIM message. Instead, the presence of the content defined in [V-MSG] SHOULD be used if identification is necessary.
この識別子は情報提供のみを目的としており、メッセージをVPIMメッセージとして意味的に識別するために使用してはなりません（SHOULD NOT）。代わりに、識別が必要な場合は、[V-MSG]で定義されているコンテンツの存在を使用する必要があります（SHOULD）。
The content-type header declares the type of content enclosed in the message. The typical top level content in a VPIM Message SHOULD be multipart/voice-message, a mechanism for bundling several components into a single identifiable voice message. The allowable contents are detailed in section 4.3 of this document. From [MIME2]
content-typeヘッダーは、メッセージに含まれるコンテンツのタイプを宣言します。 VPIMメッセージの一般的な最上位コンテンツは、複数のコンポーネントを単一の識別可能な音声メッセージにバンドルするメカニズムであるmultipart / voice-messageである必要があります。許容される内容は、このドキュメントのセクション4.3で詳しく説明されています。 [MIME2]から
Because Internet mail was initially specified to carry only 7-bit US-ASCII text, it may be necessary to encode voice and fax data into a representation suitable for that environment. The content-transfer-encoding header describes this transformation if it is needed. Compliant implementations MUST recognize and decode the standard encodings, "Binary", "7bit, "8bit", "Base64" and "Quoted-Printable". The allowable content-transfer-encodings are specified in section 4.3. From [MIME1]
インターネットメールは当初、7ビットのUS-ASCIIテキストのみを伝送するように指定されていたため、音声およびFAXデータをその環境に適した表現にエンコードする必要がある場合があります。 content-transfer-encodingヘッダーは、必要な場合にこの変換を記述します。準拠する実装は、標準のエンコーディング「バイナリ」、「7ビット、「8ビット」、「Base64」、および「Quoted-Printable」を認識およびデコードする必要があります。許可されるcontent-transfer-encodingsは、セクション4.3で指定されています。[MIME1]から
The sensitivity header, if present, indicates the requested privacy level. The case-insensitive values "Personal" and "Private" are specified. If no privacy is requested, this field is omitted.
機密性ヘッダーがある場合は、要求されたプライバシーレベルを示します。大文字と小文字を区別しない値「Personal」と「Private」が指定されています。プライバシーが要求されない場合、このフィールドは省略されます。
If a sensitivity header is present in the message, a compliant system MUST prohibit the recipient from forwarding this message to any other user. A compliant system, however, SHOULD allow the responder to reply to a sensitive message, but SHOULD NOT include the original message content. The sensitivity of the reply message MAY be set by the responder.
機密性ヘッダーがメッセージに存在する場合、準拠システムは、受信者がこのメッセージを他のユーザーに転送することを禁止する必要があります。ただし、準拠システムでは、レスポンダが機密メッセージに返信できるようにする必要があります（SHOULD）が、元のメッセージの内容を含めないでください（SHOULD NOT）。応答メッセージの感度は、レスポンダによって設定される場合があります。
If the receiving system does not support privacy and the sensitivity is one of "Personal" or "Private", a negative delivery status notification must sent to the originator with the appropriate status code 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]
受信側システムがプライバシーをサポートせず、機密性が「個人」または「プライベート」のいずれかである場合、否定的な配信ステータス通知は、プライバシーを保証できなかったことを示す適切なステータスコードとともに発信者に送信する必要があります。メッセージの内容は送信者に返されるべきであり（SHOULD）、通知を伴う音声コンテキストを可能にします。プライベートメッセージへの配信不能通知は、発信者に送信されるため、プライベートタグを付けないでください。差出人：[X.400]
Indicates the requested importance to be given by the receiving system. The case-insensitive values "low", "normal" and "high" are specified. If no special importance is requested, this header may be omitted and the value assumed to be "normal".
受信側システムによって与えられる要求された重要度を示します。大文字と小文字を区別しない「低」、「通常」、「高」の値が指定されています。特別な重要性が要求されない場合、このヘッダーは省略され、値は「通常」と見なされます。
Compliant implementations MAY use this header to indicate the importance of a message and may order messages in a recipient's mailbox. From: [X.400]
準拠した実装は、このヘッダーを使用してメッセージの重要性を示してもよく（MAY）、受信者のメールボックスでメッセージを順序付けしてもよい。差出人：[X.400]
The subject field is often provided by email systems but is not widely supported on Voice Mail platforms. For compatibility with text based mailbox interfaces, a text subject field SHOULD be generated by a compliant implementation but MAY be discarded if present by a receiving system. From [RFC822]
件名フィールドは、多くの場合電子メールシステムによって提供されますが、ボイスメールプラットフォームでは広くサポートされていません。テキストベースのメールボックスインターフェイスとの互換性のために、テキストの件名フィールドは準拠した実装によって生成される必要があります（SHOULD）が、受信システムによって存在する場合は破棄される場合があります。 [RFC822]から
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" for the benefit of text enabled recipients.
テキスト対応の受信者のために、テキストユーザーインターフェイスをサポートしないボイスメッセージングシステム（電話によるアクセスのみなど）では、「VPIMメッセージ」という一般的な件名ヘッダーを挿入することをお勧めします。
This header MAY be present to indicate that the sender is requesting a receipt notification from the receiving user agent. This message disposition notification (MDN) is typically sent by the user agent after the user has listened to the message and consented to an MDN being sent
このヘッダーは、送信者が受信ユーザーエージェントからの受信通知を要求していることを示すために存在する場合があります。このメッセージ処理通知（MDN）は、通常、ユーザーがメッセージを聞いてMDNの送信に同意した後にユーザーエージェントによって送信されます。
Example:
例：
Disposition-notification-to: +12145551213@mycompany.com
The presence of a Disposition-notification-to header in a message is merely a request for an MDN described in 4.4.5. The recipients' user agents are always free to silently ignore such a request so this header does not burden any system that does not support it. From [MDN].
メッセージ内のDisposition-notification-toヘッダーの存在は、4.4.5で説明されているMDNの要求にすぎません。受信者のユーザーエージェントはいつでもこのような要求を黙って無視することができるため、このヘッダーはそれをサポートしないシステムに負担をかけません。 [MDN]から。
This header MAY be present to define future extensions parameters for an MDN requested by the presence of the header in the previous section. Currently no parameters are defined by this document or by [MDN]. However, this header MUST be parsed if present, if MDNs are supported. If it contains a extension parameter that is required for proper MDN generation (noted with "=required"), then an MDN MUST NOT be sent if the parameter is not understood. See [MDN] for complete details.
このヘッダーは、前のセクションのヘッダーの存在によって要求されたMDNの将来の拡張パラメータを定義するために存在する場合があります。現在、このドキュメントまたは[MDN]によって定義されているパラメーターはありません。ただし、MDNがサポートされている場合、このヘッダーは存在する場合は解析する必要があります。適切なMDN生成に必要な拡張パラメーター（ "= required"で示される）が含まれている場合、パラメーターが理解されていない場合、MDNを送信してはなりません（MUST NOT）。詳細については、[MDN]を参照してください。
Example:
例：
Disposition-notification-options: whizzbang=required,foo
ディスポジション通知オプション：whizzbang = required、foo
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 header field) is in addition to the audio encoding required to generate a binary object.
[MIME1]で導入されたMIMEは、幅広いボディパーツを伝送するために拡張可能な汎用メッセージボディフォーマットです。 7ビットのテキスト指向のSMTPプロトコルで転送できるように、バイナリデータのエンコードを提供します。このトランスポートエンコーディング（Content-Transfer-Encodingヘッダーフィールドで示される）は、バイナリオブジェクトの生成に必要なオーディオエンコーディングに追加されます。
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ビット表現に変換するための2つのトランスポートエンコーディングメカニズムを定義します。 Base64はオーディオデータに対して劇的に効率的ですが、どちらでも機能します。バイナリトランスポートが利用可能な場合、トランスポートエンコーディングは不要であり、データは「バイナリ」としてラベル付けできます。
An implementation in compliance with this profile SHOULD send audio and/or facsimile data in binary form when binary message transport is available. When binary transport is not available, implementations MUST encode the audio and/or facsimile data as Base64. The detection and decoding of "Quoted-Printable", "7bit", and "8bit" MUST be supported in order to meet MIME requirements and to preserve interoperability with the fullest range of possible devices. However, if a content is received in a transfer encoding that cannot be rendered to the user, an appropriate negative delivery status notification MUST be sent.
このプロファイルに準拠した実装では、バイナリメッセージトランスポートが利用可能な場合、オーディオおよび/またはファクシミリデータをバイナリ形式で送信する必要があります。バイナリトランスポートが利用できない場合、実装はオーディオおよび/またはファクシミリデータをBase64としてエンコードする必要があります。 「Quoted-Printable」、「7bit」、および「8bit」の検出とデコードは、MIME要件を満たし、可能なデバイスの全範囲との相互運用性を維持するためにサポートする必要があります。ただし、ユーザーにレンダリングできない転送エンコーディングでコンテンツを受信した場合は、適切な否定配信ステータス通知を送信する必要があります。
The content types described in this section are identified for use within the multipart/voice-message content. This content, which is the fundamental part of a VPIM message, is referred to as a VPIM voice message in this document.
このセクションで説明するコンテンツタイプは、multipart / voice-messageコンテンツ内で使用するために識別されています。このコンテンツは、VPIMメッセージの基本的な部分であり、このドキュメントではVPIMボイスメッセージと呼ばれます。
Only the contents profiled subsequently can be sent within a VPIM voice message construct (i.e., the mulitpart/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 an error condition and SHOULD result in a negative delivery status notification. When multiple contents are present within the multipart/voice-message, they SHOULD be presented to the user in the order that they appear in the message.
VPIMボイスメッセージコンストラクト（つまり、マルチパート/ボイスメッセージコンテンツタイプ）内で後でプロファイリングされたコンテンツのみを送信して、単純なまたはより複雑な構造を形成できます（いくつかの例を付録Bに示します）。 VPIMボイスメッセージ内の他のコンテンツの存在はエラー状態であり、否定的な配信ステータス通知が発生する必要があります。 multipart / voice-message内に複数のコンテンツが存在する場合、それらはメッセージに表示される順序でユーザーに提示されるべきです（SHOULD）。
This MIME multipart structure provides a mechanism for packaging a voice message into one container that is tagged as VPIM v2 compliant. The semantic of multipart/Voice-Message (defined in [V-MSG]) is identical to multipart/mixed and may be interpreted as that by systems that do not recognize this content-type.
このMIMEマルチパート構造は、VPIM v2準拠としてタグ付けされた1つのコンテナーに音声メッセージをパッケージ化するメカニズムを提供します。 multipart / Voice-Message（[V-MSG]で定義）のセマンティクスはmultipart / mixedと同じであり、このコンテンツタイプを認識しないシステムによって解釈される場合があります。
The Multipart/Voice-Message content-type MUST only contain the profiled media and content types specified in this section (i.e. audio/*, image/*, message/rfc822 and text/directory). The most common will be: spoken name, spoken subject, the message itself, attached fax and directory info. Forwarded messages are created by simply using the message/rfc822 construct.
Multipart / Voice-Message content-typeには、このセクションで指定されたプロファイル化されたメディアとコンテンツタイプ（すなわち、audio / *、image / *、message / rfc822およびtext / directory）のみを含める必要があります。最も一般的なものは、音声名、音声サブジェクト、メッセージ自体、添付されたFAXとディレクトリ情報です。転送されたメッセージは、message / rfc822コンストラクトを使用するだけで作成されます。
Conformant implementations MUST send the multipart/voice-message in a VPIM message. In most cases, this Multipart/Voice-Message content will be the top level (i.e. in the Content-Type header). Conformant implementations MUST recognize the Multipart/Voice-Message content (whether it is a top level content or below a multipart/mixed) and be able to separate the contents (e.g. spoken name or spoken subject).
準拠した実装は、VPIMメッセージでmultipart / voice-messageを送信する必要があります。ほとんどの場合、このMultipart / Voice-Messageコンテンツはトップレベルになります（つまり、Content-Typeヘッダー内）。準拠する実装は、Multipart / Voice-Messageのコンテンツを認識し（トップレベルのコンテンツであるか、multipart / mixedの下であるか）、コンテンツを分離できる必要があります（たとえば、口頭での名前や口頭での主題）。
MIME requires support of the Message/RFC822 message encapsulation body part. This body part is used within a multipart/voice-message to forward complete messages (see 4.5) or to reply with original content (see 4.6). From [MIME2]
MIMEは、Message / RFC822メッセージカプセル化の本文部分のサポートを必要とします。この本文部分はmultipart / voice-message内で使用され、完全なメッセージを転送するか（4.5を参照）、元のコンテンツで返信します（4.6を参照）。 [MIME2]から
This content allows for the inclusion of a Versit vCard [VCARD] electronic business card within a VPIM message. The format is suitable as an interchange format between applications or systems, and is defined independent of the method used to transport it. It provides a useful mechanism to transport information about the originator that can be used by the receiving VPIM system (see 6) or other local applications
このコンテンツでは、VPIMメッセージ内にVersit vCard [VCARD]電子名刺を含めることができます。この形式は、アプリケーションまたはシステム間の交換形式として適しており、転送に使用される方法とは無関係に定義されます。受信側のVPIMシステム（6を参照）またはその他のローカルアプリケーションで使用できる発信者に関する情報を転送するための便利なメカニズムを提供します
Each vCard MUST be contained within a Text/Directory content type [MIMEDIR] within a VPIM message. [MIMEDIR] requires that the character set MUST be defined as a parameter value (typically us-ascii for VPIM) and that the profile SHOULD be defined (the value MUST be vCard within VPIM messages).
各vCardは、VPIMメッセージ内のテキスト/ディレクトリコンテンツタイプ[MIMEDIR]に含める必要があります。 [MIMEDIR]では、文字セットをパラメーター値（通常はVPIMのus-ascii）として定義する必要があり、プロファイルを定義する必要があります（値はVPIMメッセージ内のvCardでなければなりません）。
Each VPIM message SHOULD be created with a Text/Directory (vCard profile) content type that MUST contain the preferred email address, telephone number, and text name of the message originator as well as the vCard version. The vCard SHOULD contain the spoken name and role of the originator, as well as the revision date. Any other vCard attribute MAY also be present. The intent is that the vCard be used as the source of information to contact the originator (e.g., reply, call).If the text/directory content-type is included in a VPIM message, the vCard profile [VCARD] MUST be used and MUST specify at least the following attributes:
各VPIMメッセージは、テキスト/ディレクトリ（vCardプロファイル）コンテンツタイプで作成する必要があります（SHOULD）。優先メールアドレス、電話番号、メッセージ発信者のテキスト名、およびvCardバージョンを含める必要があります。 vCardには、発言者の名前と役割、および改訂日が含まれている必要があります（SHOULD）。その他のvCard属性も存在する場合があります。その意図は、vCardを発信者に連絡するための情報源として使用することです（たとえば、返信、通話）。text/ directory content-typeがVPIMメッセージに含まれている場合、vCardプロファイル[VCARD]を使用する必要があります。少なくとも以下の属性を指定する必要があります。
TEL - Public switched telephone number in international (E.164) format (various types, typically VOICE)
TEL-国際（E.164）形式の公衆交換電話番号（さまざまなタイプ、通常はVOICE）
EMAIL - email address (various types, typically INTERNET; the type VPIM is optionally used to denote an address that supports VPIM messages(see 18.1))
電子メール-電子メールアドレス（さまざまなタイプ、通常はインターネット。タイプVPIMは、VPIMメッセージをサポートするアドレスを示すためにオプションで使用されます（18.1を参照））
VERSION - Indicates the version of the vCard profile. Version 3.0 [VCARD] MUST be used.
VERSION-vCardプロファイルのバージョンを示します。バージョン3.0 [VCARD]を使用する必要があります。
The following attributes SHOULD be specified:
次の属性を指定する必要があります。
N - Family Name, Given Name, Additional Names, Honorific Prefixes, and Suffixes. Because it is expected that recipients using a telephone user interface will use the information in the vCard to identify the originator, and the GUI will see the information presented in the FROM line, all present components in the text name of the FROM header field MUST match the values provided by the Vcard.
N-姓、名、追加名、敬称、接尾辞。電話ユーザーインターフェイスを使用する受信者はvCardの情報を使用して発信者を識別し、GUIがFROM行に表示される情報を表示することが予想されるため、FROMヘッダーフィールドのテキスト名に含まれるすべてのコンポーネントは一致する必要があります。 Vcardによって提供される値。
ROLE - The role of the person identified in `N' or `FN', but may also be used to distinguish when the sender is a corporate or positional mailbox
ROLE-「N」または「FN」で識別される人物の役割ですが、送信者が企業または定型メールボックスである場合を区別するために使用することもできます
SOUND - spoken name sound data (various types, typically 32KADPCM)
SOUND-音声名音声データ（さまざまなタイプ、通常32KADPCM）
REV - Revision of vCard in ISO 8601 date format
REV-ISO 8601日付形式のvCardのリビジョン
The vCard MAY use other attributes as defined in [VCARD] or extensions attributes not yet defined (e.g. capabilities).
vCardは、[VCARD]で定義されている他の属性、またはまだ定義されていない拡張属性（機能など）を使用してもよい（MAY）。
If present, the spoken name attribute MUST be denoted by a content ID
pointing to an audio/* content elsewhere in the VPIM message.
A typical VPIM message (i.e. no forwarded parts), MUST only contain one vCard -- more than one is an error condition. A VPIM message that contains forwarded messages, though, may contain multiple vCards. However, these vCards MUST be associated with the originator(s) of the forwarded message(s) and the originator of the forwarding message. As a result, all forwarded vCards will be contained in message/rfc822 contents -- only the vCard of forwarding originator will be at the top-level.
典型的なVPIMメッセージ（つまり、転送された部分はありません）には、vCardを1つだけ含める必要があります-複数の場合はエラー状態です。ただし、転送されたメッセージを含むVPIMメッセージには、複数のvCardが含まれる場合があります。ただし、これらのvCardは、転送されたメッセージの発信者と転送メッセージの発信者に関連付けられている必要があります。その結果、転送されたすべてのvCardはmessage / rfc822のコンテンツに含まれます。転送元のvCardのみが最上位になります。
Example:
例：
Content-Type: text/directory; charset=us-ascii; profile=vCard
Content-Transfer-Encoding: 7bit
BEGIN:VCARD
N:Parsons;Glenn
ORG:Northern Telecom
TEL;TYPE=VOICE;MSG;WORK:+1-613-763-7582
EMAIL;TYPE=INTERNET;glenn.parsons@nortel.ca
EMAIL;TYPE=INTERNET;VPIM:6137637582@vm.nortel.ca
SOUND;TYPE=32KADPCM;ENCODING=URI: CID:<part1@VM2-4321>
REV:19960831T103310Z
VERSION: 3.0
END:VCARD
An implementation compliant to this profile MUST send Audio/32KADPCM by default for voice [ADPCM]. Receivers MUST be able to accept and decode Audio/32KADPCM. Typically this body contains several minutes of message content, however if used for spoken name or subject the content should be considerably shorter (i.e. about 10 and 20 seconds respectively).
このプロファイルに準拠する実装は、デフォルトで音声用にAudio / 32KADPCMを送信する必要があります[ADPCM]。レシーバーはAudio / 32KADPCMを受け入れてデコードできる必要があります。通常、この本文には数分のメッセージコンテンツが含まれますが、口頭での名前または件名に使用する場合、コンテンツはかなり短くなります（つまり、それぞれ約10秒と20秒）。
If an implementation can only handle one voice body, then multiple voice bodies (if present) SHOULD be concatenated, and SHOULD NOT be discarded. It is RECOMMENDED that this be done in the same order as they were sent. Note that if an Originator Spoken Name audio body and a vCard are both present in a VPIM message, the vCard SOUND attribute MUST point to this audio body (see 4.3.3).
実装が1つの音声本文のみを処理できる場合は、複数の音声本文（存在する場合）を連結する必要があり（SHOULD）、破棄する必要はありません（SHOULD NOT）。これは、送信されたのと同じ順序で実行することをお勧めします。 Originator Spoken Nameオーディオ本文とvCardの両方がVPIMメッセージに存在する場合、vCard SOUND属性はこのオーディオ本文を指す必要があることに注意してください（4.3.3を参照）。
While any valid MIME body header MAY be used, several header fields have the following semantics when included with this body part:
任意の有効なMIMEボディヘッダーを使用できますが、このボディパーツに含まれる場合、いくつかのヘッダーフィールドには次のセマンティクスがあります。
4.3.4.1 Content-Description:
4.3.4.1 コンテンツの説明：
This field MAY be present to facilitate the text identification of these body parts in simple email readers. Any values may be used, though it may be useful to use values similar to those for Content-Disposition.
このフィールドは、シンプルな電子メールリーダーでこれらのボディパーツのテキスト識別を容易にするために存在する場合があります。 Content-Dispositionと同様の値を使用すると便利な場合がありますが、任意の値を使用できます。
Example:
例：
Content-Description: Big Telco Voice Message
コンテンツの説明：大きな電話会社のボイスメッセージ
4.3.4.2 Content-Disposition:
4.3.4.2 コンテンツ処理：
This field MUST be present to allow the parsable identification of these body parts. This is especially useful if, as is typical, more than one Audio/32KADPCM body occurs within a single level (e.g. multipart/voice-message). Since a VPIM voice message is intended to be automatically played upon display of the message, in the order in which the audio contents occur, the audio contents must always be of type inline. However, it is still useful to include a filename value, so this should be present if this information is available. From [DISP]
このフィールドは、これらの身体部分の解析可能な識別を可能にするために存在しなければなりません。これは、通常のように、単一のレベル内で複数のAudio / 32KADPCMボディが発生する場合に特に役立ちます（例：multipart / voice-message）。 VPIMボイスメッセージは、メッセージの表示時に自動的に再生されるように意図されているため、オーディオコンテンツが発生する順序で、オーディオコンテンツは常にインラインタイプである必要があります。ただし、ファイル名の値を含めることは依然として有用であるため、この情報が利用可能な場合は、これが存在する必要があります。 [DISP]から
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 parameter values below to be used as appropriate (see 18.2):
VPIM音声メッセージ内のさまざまなタイプのオーディオコンテンツを区別するために、新しい処理パラメータ「音声」が以下のパラメータ値で定義され、必要に応じて使用されます（18.2を参照）。
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
Voice-Message-プライマリ音声メッセージ、Voice-Message-Notification-音声配信通知または音声処理通知、Originator-Spoken-Name-発信者の音声名、Recipient-Spoken-Name-受信者の音声名発信者が利用でき、受信者が1人だけの場合に表示されます。Spoken-Subject-メッセージの音声の件名。通常は発信者が話します。
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.
メッセージレベルごとに、これらのタイプのオーディオコンテンツの各インスタンスが1つだけ存在する必要があることに注意してください。添付された転送音声メッセージ内で、特定のタイプ（パラメータ値など）の追加インスタンスが発生する場合があります。
Implementations that do not understand the "voice" parameter (or the Content-Disposition header) can safely ignore it, and will present the audio bodyparts in order (but will not be able to distinguish between them).
「voice」パラメーター（またはContent-Dispositionヘッダー）を理解しない実装は、それを安全に無視でき、オーディオボディパーツを順番に表示します（ただし、それらを区別することはできません）。
Example:
例：
Content-Disposition: inline; voice=spoken-subject;
filename="msg001.726"
4.3.4.3 Content-Duration:
4.3.4.3 Content-Duration：
This field MAY be present to allow the specification of the length of the audio bodypart in seconds. The use of this field on reception is a local implementation issue. From [DUR]
このフィールドは、オーディオボディパートの長さを秒単位で指定できるようにするために存在してもよい（MAY）。受信時にこのフィールドを使用することは、ローカル実装の問題です。 [DUR]から
Example:
例：
Content-Duration: 33
コンテンツ期間：33
4.3.4.4 Content-Language:
4.3.4.4 コンテンツ言語：
This field MAY be present to allow the specification of the spoken language of the audio bodypart. The encoding is defined in [LANG]. The use of this field on reception is a local implementation issue.
このフィールドは、オーディオボディパートの話された言語の指定を可能にするために存在してもよい（MAY）。エンコーディングは[LANG]で定義されています。受信時にこのフィールドを使用することは、ローカル実装の問題です。
Example for UK English:
英国英語の例：
Content-Language: en-UK
コンテンツ言語：en-UK
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 in a VPIM 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として知られているファクシミリの一般的な画像エンコーディングは、Tag Image File Format（TIFF）の派生物であり、いくつかのドキュメントで説明されています。 VPIMの目的のために、ファクシミリ用のTIFFのFプロファイル（TIFF-F）は[TIFF-F]で定義され、イメージ/ tiff MIMEコンテンツタイプは[TIFFREG]で定義されます。 TIFFにはいくつかの形式がありますが、VPIMボイスメッセージで使用するためにプロファイリングされるのはTIFF-Fだけです。さらに、TIFF-Fファイル形式はVPIMのストアアンドフォワードモードで使用されるため、ファクシミリページごとに1つの画像ストリップのみが存在するように画像をエンコードする必要があります。
All VPIM implementations that support facsimile SHOULD generate TIFF-F compatible facsimile contents in the image/tiff; application=faxbw sub-type encoding by default. An implementation MAY send this fax content in VPIM voice messages and MUST be able to recognize and display it in received messages. If a fax message is received that cannot be rendered to the user (e.g. the receiving VPIM system does not support fax), then the system MUST return the message with a negative delivery status notification with a media not supported status code.
ファクシミリをサポートするすべてのVPIM実装は、イメージ/ tiffにTIFF-F互換のファクシミリコンテンツを生成する必要があります。デフォルトではapplication = faxbwサブタイプエンコーディング。実装は、このFAXコンテンツをVPIMボイスメッセージで送信する場合があり、受信したメッセージで認識して表示できる必要があります。ユーザーに表示できないFAXメッセージを受信した場合（受信VPIMシステムがFAXをサポートしていないなど）、システムは、メディアがサポートされていないステータスコードを含む否定的な配信ステータス通知を含むメッセージを返す必要があります。
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. However, inbound messages with or without this parameter MUST be rendered to the user (if the rendering software encounters an error in the file format, some form of negative delivery status notification MUST be sent to the originator).
有効なMIMEボディヘッダーを使用してもかまいませんが（たとえば、ファイル名を示すContent-Disposition）、VPIMの特別なセマンティクスを持つものは指定されず、無視される場合があります。コンテンツタイプパラメータapplication = faxbwがアウトバウンドメッセージに含まれている必要があることに注意してください。ただし、このパラメーターの有無にかかわらず、受信メッセージはユーザーにレンダリングする必要があります（レンダリングソフトウェアでファイル形式のエラーが発生した場合は、何らかの否定的な配信ステータス通知を発信者に送信する必要があります）。
Proprietary voice or fax encoding formats or other standard formats MAY be supported under this profile provided a unique identifier is registered with the IANA prior to use (see [MIME4]). The voice encodings should be registered as sub-types of Audio and the fax encodings should be registered as sub-types of Image
固有の識別子が使用前にIANAに登録されている場合（[MIME4]を参照）、独自の音声またはFAXエンコード形式または他の標準形式がこのプロファイルでサポートされる場合があります。音声エンコーディングはオーディオのサブタイプとして登録する必要があり、ファックスエンコーディングはイメージのサブタイプとして登録する必要があります
Use of any other encoding except audio/32kadpcm or image/tiff; application=faxbw reduces interoperability in the absence of explicit manual system configuration. A compliant implementation MAY use any other encoding with explicit per-destination configuration.
audio / 32kadpcmまたはimage / tiff以外のエンコーディングの使用。 application = faxbwは、明示的な手動システム構成がない場合の相互運用性を低下させます。準拠した実装は、宛先ごとの明示的な構成で他のエンコーディングを使用してもよい（MAY）。
An implementation compliant with this profile MAY send additional contents in a VPIM message, but ONLY outside of the multipart/voice-message. The content types described in this section are identified for use with this profile. Additional contents not defined in this profile MUST NOT be used without prior explicit per-destination configuration. If an implementation receives a VPIM message that contains content types not specified in this profile, their handling is a local implementation issue (e.g. the unknown contents MAY be discarded if they cannot be presented to the recipient). Conversely, if an implementation receives a non-VPIM message (i.e., without a mulitpart/voice-message content type) with any of the contents defined in 4.3 & 4.4, it SHOULD deliver those contents, but the full message handling is a local issue (e.g. the unknown contents _or_ the entire message MAY be discarded). Implementations MUST issue negative delivery status notifications to the originator when any form of non-delivery to the recipient occurs.
このプロファイルに準拠する実装は、VPIMメッセージで追加のコンテンツを送信できますが、multipart / voice-messageの外部でのみ送信できます。このセクションで説明するコンテンツタイプは、このプロファイルで使用するために識別されています。このプロファイルで定義されていない追加のコンテンツは、事前の明示的な宛先ごとの構成なしに使用してはなりません。このプロファイルで指定されていないコンテンツタイプを含むVPIMメッセージを実装が受信した場合、それらの処理はローカルの実装の問題です（たとえば、不明なコンテンツは受信者に提示できない場合は破棄される場合があります）。逆に、実装が4.3および4.4で定義されたいずれかのコンテンツを含む非VPIMメッセージを受信する場合（つまり、マルチパート/音声メッセージコンテンツタイプなし）、それらのコンテンツを配信する必要がありますが、完全なメッセージ処理はローカルの問題です（例えば、未知の内容_or_メッセージ全体が破棄されるかもしれません）。実装は、受信者への何らかの配信不能が発生した場合、発信者に否定的な配信ステータス通知を発行する必要があります。
The multipart contents defined below MAY be sent as the top level of a VPIM message (with other noted contents below them as required.) As well, the multipart/mixed content SHOULD be used as the top level of a VPIM message to form a more complex structure (e.g., with additional content types). When multiple contents are present, they SHOULD be presented to the user in the order that they appear in the message. Several examples are given in Appendix B.
以下で定義されたマルチパートコンテンツは、VPIMメッセージのトップレベルとして送信される場合があります（必要に応じて、他の注記されたコンテンツがその下に送信されます）。また、マルチパート/混合コンテンツは、VPIMメッセージのトップレベルとして使用して、複雑な構造（例：追加のコンテンツタイプ）。複数のコンテンツが存在する場合、それらはメッセージに表示される順序でユーザーに提示されるべきです（SHOULD）。いくつかの例を付録Bに示します。
MIME provides the facilities for enclosing several body parts in a single message. Multipart/Mixed SHOULD only be used for sending complex voice or multimedia messages. That is, as the top level Content-Type when sending one of the following contents (in addition to the VPIM voice message) in a VPIM message. Compliant systems MUST accept multipart/mixed body parts. From [MIME2]
MIMEは、複数のボディパーツを単一のメッセージで囲む機能を提供します。 Multipart / Mixedは、複雑な音声またはマルチメディアメッセージの送信にのみ使用してください。つまり、VPIMメッセージで（VPIMボイスメッセージに加えて）次のいずれかのコンテンツを送信するときの最上位のContent-Typeとして。準拠システムは、マルチパート/混合ボディパーツを受け入れる必要があります。 [MIME2]から
MIME requires support of the basic Text/Plain content type. This content type has limited applicability within the voice messaging environment. However, because VPIM is a MIME profile, MIME requirements should be met. Compliant VPIM implementations SHOULD NOT send the Text/Plain content-type. Compliant implementations MUST accept Text/Plain messages, however, specific handling is left as an implementation decision. From [MIME2]
MIMEは、基本的なテキスト/プレーンコンテンツタイプのサポートを必要とします。このコンテンツタイプは、ボイスメッセージング環境内での適用が制限されています。ただし、VPIMはMIMEプロファイルであるため、MIME要件を満たす必要があります。準拠するVPIM実装は、テキスト/プレーンコンテンツタイプを送信しないでください。準拠した実装はテキスト/プレーンメッセージを受け入れる必要がありますが、特定の処理は実装の決定として残されます。 [MIME2]から
There are several mechanisms that can be used to support text (once accepted) on voice messaging systems including text-to-speech and text-to-fax conversions. If no rendering of the text is possible (i.e., it is not possible for the recipient to determine if the text is a critical part of the message), the entire message MUST be returned to the sender with a negative delivery status notification and a media-unsupported status code.
テキストから音声への変換やテキストからFAXへの変換など、ボイスメッセージングシステムでテキストをサポートするために使用できるメカニズムはいくつかあります。テキストのレンダリングが不可能な場合（つまり、テキストがメッセージの重要な部分であるかどうかを受信者が判断できない場合）、メッセージ全体を否定的な配信ステータス通知とメディアとともに送信者に返す必要があります。 -サポートされていないステータスコード。
The Multipart/Report is used for enclosing human-readable and machine parsable notification (e.g. Message/delivery-status) body parts and any returned message content. The multipart/report content-type is used to deliver both delivery status reports indicating transport success or failure and message disposition notifications to indicate post-delivery events such as receipt notification. Compliant implementations MUST use the Multipart/Report construct. Compliant implementations MUST recognize and decode the Multipart/Report content type and its components in order to present the report to the user. From [REPORT]
マルチパート/レポートは、人間が読み取れる、機械で解析可能な通知（メッセージ/配信ステータスなど）の本文部分と返されたメッセージの内容を囲むために使用されます。 multipart / report content-typeは、トランスポートの成功または失敗を示す配信ステータスレポートと、受信通知などの配信後のイベントを示すメッセージ処理通知の両方を配信するために使用されます。準拠した実装では、Multipart / Reportコンストラクトを使用する必要があります。準拠した実装は、レポートをユーザーに提示するために、マルチパート/レポートのコンテンツタイプとそのコンポーネントを認識およびデコードする必要があります。 [レポート]から
Multipart/Report messages from VPIM implementations SHOULD include the human-readable description of the error as a spoken audio/* content (this speech SHOULD also be made available to the notification recipient). As well, VPIM implementations MUST be able to handle (and MAY generate) Multipart/Report messages that encode the human-readable description of the error as text. Note that per [DSN] the human-readable part MUST always be present.
VPIM実装からのマルチパート/レポートメッセージには、人間が読める形式のエラーの説明が音声/ *コンテンツとして含まれている必要があります（このスピーチは通知の受信者も利用できるようにする必要があります（SHOULD））。また、VPIM実装は、人間が読める形式のエラーの説明をテキストとしてエンコードするマルチパート/レポートメッセージを処理（および生成）できなければなりません（MUST）。 [DSN]に従って、人間が読める部分が常に存在している必要があります。
This MIME body part is used for sending machine-parsable delivery status notifications. Compliant implementations MUST use the Message/delivery-status construct when returning messages or sending warnings. Compliant implementations MUST recognize and decode the Message/delivery-status content type and present the reason for failure to the sender of the message. From [DSN]
このMIMEボディ部分は、マシンが解析可能な配信ステータス通知を送信するために使用されます。準拠した実装は、メッセージを返すか警告を送信するときにMessage / delivery-statusコンストラクトを使用する必要があります。準拠した実装は、メッセージ/配信ステータスコンテンツタイプを認識してデコードし、失敗の理由をメッセージの送信者に提示する必要があります。 [DSN]から
This MIME body part is used for sending machine-parsable receipt notification message disposition notifications. Conforming implementations SHOULD use the Message/Disposition-notification construct when sending post-delivery message status notifications. These MDNs, however, MUST only be sent in response to the presence of the Disposition-notification-to header in 4.2.16. Conforming implementations should recognize and decode the Message/Disposition-notification content type and present the notification to the user. From [MDN]
このMIMEボディ部分は、機械で解析可能な受信通知メッセージの処理通知を送信するために使用されます。適合実装は、配信後メッセージステータス通知を送信するときに、メッセージ/ディスポジション通知コンストラクトを使用する必要があります（SHOULD）。ただし、これらのMDNは、4.2.16のDisposition-notification-toヘッダーの存在に応答してのみ送信する必要があります。適合実装は、メッセージ/廃棄通知コンテンツタイプを認識およびデコードし、通知をユーザーに提示する必要があります。 [MDN]から
VPIM version 2 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バージョン2は、音声またはFAXアノテーションを使用して、音声およびFAXコンテンツの転送を明示的にサポートします。ただし、VPIMメッセージで受け入れられるのは、次に説明する2つの構成のみです。最初のメッセージ（つまり、message / 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" line. However, 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 through
concatenation of the original message and the forwarding annotation,
such as must be done in a gateway between VPIM and the AMIS voice
messaging protocol, the entire audio content MAY be sent as a single
Audio/* segment without including any forwarding semantics.
Replies to VPIM messages (and Internet mail messages) are addressed to the address noted in the reply-to header (see 4.2.8) if it is present, else the From address (see 4.2.1) is used. The vCard EMAIL attribute, if present, SHOULD be the same as the reply-to address and may be the same as the From address. While the vCard is the senders preferred address it SHOULD NOT be used to generate a reply. Also, the Return-path address should not be used for replies.
VPIMメッセージ（およびインターネットメールメッセージ）への返信は、存在する場合は返信先ヘッダー（4.2.8を参照）に記載されたアドレスに送信され、それ以外の場合は送信元アドレス（4.2.1を参照）が使用されます。 vCard EMAIL属性は、存在する場合、返信先アドレスと同じである必要があり、Fromアドレスと同じである場合があります。 vCardは送信者の優先アドレスですが、返信の生成には使用しないでください。また、返信には返信パスアドレスを使用しないでください。
Support of multiple originator header fields 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 error messages and replies to their proper destinations.
ボイスメッセージングシステムでは、複数の発信元ヘッダーフィールドをサポートできないことがよくあります。そのため、VPIMメッセージを別のボイスメッセージシステムにゲートウェイ処理する場合は、1つだけを選択する必要があります。ただし、実装者は、これによりエラーメッセージおよび返信を適切な宛先に送信できない場合があることに注意する必要があります。
In some cases, a reply message is not possible, such as with a message created by telephone answering (i.e. classic voice mail). In this case, the From field MUST contain the special address non-mail-user@domain (see 4.1.2). A null ESMTP MAIL FROM address SHOULD also be used in this case (see 5.1.2). A receiving VPIM system SHOULD NOT offer the user the option to reply to this kind of message.
電話応答によって作成されたメッセージ（従来のボイスメールなど）の場合など、返信メッセージが不可能な場合があります。この場合、差出人フィールドには特別なアドレスnon-mail-user @ domainが含まれている必要があります（4.1.2を参照）。この場合、ESMTP MAIL FROMアドレスはnullにする必要があります（5.1.2を参照）。受信側のVPIMシステムでは、この種のメッセージに返信するオプションをユーザーに提供しないでください。
VPIM delivery status notification messages (4.4.4) MUST be sent to the originator of the message when any form of non-delivery of the subject message or its components occurs. These error messages must be sent to the return path (4.2.6) if present, otherwise, the From (4.2.1) address may be used.
VPIM配信ステータス通知メッセージ（4.4.4）は、サブジェクトメッセージまたはそのコンポーネントの何らかの配信不能が発生したときに、メッセージの発信者に送信する必要があります。これらのエラーメッセージは、存在する場合はリターンパス（4.2.6）に送信する必要があります。それ以外の場合は、From（4.2.1）アドレスを使用できます。
VPIM Receipt Notification messages (4.4.5) should be sent to the sender specified in the Disposition-Notification-To header field (4.2.16), only after the message has been presented to the recipient or if the message has somehow been disposed of without being presented to the recipient (e.g. if it were deleted before playing it).
VPIM受信通知メッセージ（4.4.5）は、Disposition-Notification-Toヘッダーフィールド（4.2.16）で指定された送信者に送信する必要があります。受信者に提示されずに（再生前に削除された場合など）。
VPIM Notification messages may be positive or negative, and can indicate delivery at the server or receipt by the client. However, the notification MUST be contained in a multipart/report container (4.4.3) and SHOULD contain a spoken error message.
VPIM通知メッセージは肯定的または否定的であり、サーバーでの配信またはクライアントによる受信を示すことができます。ただし、通知はマルチパート/レポートコンテナ（4.4.3）に含める必要があり、音声エラーメッセージを含める必要があります。
If a VPIM system receives a message with contents that are not understood (see 4.3 & 4.4), its handling is a local matter. A delivery status notification SHOULD be generated if the message could not be delivered because of unknown contents (e.g., on traditional voice processing systems). In some cases, the message may be delivered (with a positive DSN sent) to a mailbox before the determination of rendering can be made.
VPIMシステムが理解できない内容のメッセージを受信した場合（4.3および4.4を参照）、その処理はローカルな問題です。不明なコンテンツ（たとえば、従来の音声処理システム）のためにメッセージを配信できなかった場合、配信ステータス通知を生成する必要があります（SHOULD）。場合によっては、レンダリングの決定を行う前に、メッセージが（正のDSNで）メールボックスに配信されることがあります。
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
メッセージは、インターネット拡張シンプルメール転送プロトコル（ESMTP）を使用してボイスメールマシン間で転送されます。メッセージの適切な配信に必要なすべての情報は、ESMTPダイアログに含まれています。送信者と受信者のアドレスを含むこの情報は、一般にメッセージと呼ばれます
"envelope". This information is equivalent to the message control block in many analog voice messaging protocols.
"封筒"。この情報は、多くのアナログボイスメッセージングプロトコルのメッセージ制御ブロックに相当します。
ESMTP is a general-purpose messaging protocol, designed both to send mail and to allow terminal console messaging. Simple Mail Transport Protocol (SMTP) was originally created for the exchange of US-ASCII 7-bit text messages. Binary and 8-bit text messages have traditionally been transported by encoding the messages into a 7-bit text-like form. [ESMTP] formalized an extension mechanism for SMTP, and subsequent RFCs have defined 8-bit text networking, command streaming, binary networking, and extensions to permit the declaration of message size for the efficient transmission of large messages such as multi-minute voice mail.
ESMTPは、メールの送信と端末コンソールのメッセージングを可能にするために設計された汎用メッセージングプロトコルです。 Simple Mail Transport Protocol（SMTP）は、もともとUS-ASCII 7ビットテキストメッセージの交換用に作成されました。バイナリおよび8ビットのテキストメッセージは、従来、メッセージを7ビットのテキストのような形式にエンコードすることによって転送されてきました。 [ESMTP] SMTPの拡張メカニズムを正式化し、後続のRFCは8ビットのテキストネットワーキング、コマンドストリーミング、バイナリネットワーキング、および拡張を定義して、メッセージサイズを宣言して、数分にわたるボイスメールなどの大きなメッセージを効率的に送信できるようにしました。
The following sections list ESMTP commands, keywords, and parameters that are required and those that are optional for conformance to this profile.
次のセクションでは、このプロファイルに準拠するために必要な、およびオプションのESMTPコマンド、キーワード、およびパラメーターをリストします。
Base SMTP greeting and identification of sender. This command is not to be sent by compliant systems unless the more-capable EHLO command is not accepted. It is included for compatibility with general SMTP implementations. Compliant servers MUST implement the HELO command for backward compatibility but clients SHOULD NOT send it unless EHLO is not supported. From [SMTP]
基本的なSMTPグリーティングと送信者の識別。このコマンドは、対応可能なEHLOコマンドが受け入れられない限り、準拠システムによって送信されません。一般的なSMTP実装との互換性のために含まれています。準拠サーバーは、下位互換性のためにHELOコマンドを実装する必要がありますが、EHLOがサポートされていない場合を除き、クライアントはそれを送信しないでください。 [SMTP]から
Originating mailbox. This address contains the mailbox to which errors should be sent. VPIM implementations SHOULD use the same address in the MAIL FROM command as is used in the From header field. This address is not necessarily the same as the message Sender listed in the message header fields if the message was received from a gateway or sent to an Internet-style mailing list. From [SMTP, ESMTP]
元のメールボックス。このアドレスには、エラーの送信先となるメールボックスが含まれています。 VPIM実装は、MAIL FROMコマンドでFromヘッダーフィールドで使用されているのと同じアドレスを使用する必要があります（SHOULD）。このアドレスは、メッセージがゲートウェイから受信されたか、インターネット形式のメーリングリストに送信された場合、メッセージヘッダーフィールドにリストされたメッセージ送信者と必ずしも同じではありません。 [SMTP、ESMTP]から
The MAIL FROM address SHOULD be stored in the local message store for the purposes of generating a delivery status notification to the originator. The address indicated in the MAIL FROM command SHOULD be passed as a local system parameter or placed in a Return-Path: line inserted at the beginning of a VPIM message. From [HOSTREQ]
MAIL FROMアドレスは、発信者への配信ステータス通知を生成するために、ローカルメッセージストアに格納する必要があります（SHOULD）。 MAIL FROMコマンドで指定されたアドレスは、ローカルシステムパラメータとして渡されるか、VPIMメッセージの先頭に挿入されたReturn-Path：行に配置する必要があります（SHOULD）。 [HOSTREQ]から
Since delivery status notifications MUST be sent to the MAIL FROM address, the use of the null address ("<>") is often used to prevent looping of messages. This null address MAY be used to note that a particular message has no return path (e.g. a telephone answer message). From [SMTP]
配信ステータス通知はMAIL FROMアドレスに送信する必要があるため、メッセージのループを防ぐためにnullアドレス（ "<>"）を使用することがよくあります。このnullアドレスは、特定のメッセージ（電話応答メッセージなど）に戻りパスがないことに注意してください。 [SMTP]から
Recipient's mailbox. The parameter to this command contains only the address to which the message should be delivered for this transaction. It is the set of addresses in one or more RCPT TO commands that are used for mail routing. From [SMTP, ESMTP]
受信者のメールボックス。このコマンドのパラメーターには、このトランザクションでメッセージを配信する必要があるアドレスのみが含まれます。メールのルーティングに使用されるのは、1つ以上のRCPT TOコマンド内のアドレスのセットです。 [SMTP、ESMTP]から
Note: In the event that multiple transport connections to multiple destination machines are required for the same message, the set of addresses in a given transport connection may not match the list of recipients in the message header fields.
注：同じメッセージに複数の宛先マシンへの複数のトランスポート接続が必要な場合、特定のトランスポート接続のアドレスのセットは、メッセージヘッダーフィールドの受信者のリストと一致しない場合があります。
Initiates the transfer of message data. Support for this command is required. Compliant implementations MUST implement the SMTP DATA command for backwards compatibility. From [SMTP]
メッセージデータの転送を開始します。このコマンドのサポートが必要です。準拠した実装は、下位互換性のためにSMTP DATAコマンドを実装する必要があります。 [SMTP]から
Requests a change-of-roles, that is, the client that opened the connection offers to assume the role of server for any mail the remote machine may wish to send. Because SMTP is not an authenticated protocol, the TURN command presents an opportunity to improperly fetch mail queued for another destination. Compliant implementations SHOULD NOT implement the TURN command. From [SMTP]
役割の変更を要求します。つまり、接続を開いたクライアントは、リモートマシンが送信する可能性のあるメールのサーバーの役割を引き受けることを提案します。 SMTPは認証されたプロトコルではないため、TURNコマンドは、別の宛先のキューに入れられたメールを不適切にフェッチする機会を提供します。準拠した実装は、TURNコマンドを実装してはなりません（SHOULD NOT）。 [SMTP]から
Requests that the connection be closed. If accepted, the remote machine will reset and close the connection. Compliant implementations MUST implement the QUIT command. From [SMTP]
接続を閉じるように要求します。受け入れられると、リモートマシンはリセットして接続を閉じます。準拠した実装は、QUITコマンドを実装する必要があります。 [SMTP]から
Resets the connection to its initial state. Compliant implementations MUST implement the RSET command. From [SMTP]
接続を初期状態にリセットします。準拠した実装では、RSETコマンドを実装する必要があります。 [SMTP]から
Requests verification that this node can reach the listed recipient. While this functionality is also included in the RCPT TO command, VRFY allows the query without beginning a mail transfer transaction. This command is useful for debugging and tracing problems. Compliant implementations MAY implement the VRFY command. From [SMTP] (Note that the implementation of VRFY may simplify the guessing of a recipient's mailbox or automated sweeps for valid mailbox addresses, resulting in a possible reduction in privacy. Various implementation techniques may be used to reduce the threat, such as limiting the number of queries per session.) From [SMTP]
このノードがリストされた受信者に到達できることの確認を要求します。この機能はRCPT TOコマンドにも含まれていますが、VRFYではメール転送トランザクションを開始せずにクエリを実行できます。このコマンドは、問題のデバッグとトレースに役立ちます。適合実装は、VRFYコマンドを実装してもよい（MAY）。 [SMTP]から（VRFYの実装により、受信者のメールボックスの推測や有効なメールボックスアドレスの自動スイープが簡略化され、プライバシーが低下する可能性があることに注意してください。脅威を減らすために、さまざまな実装手法を使用して、セッションあたりのクエリ数。）[SMTP]から
The enhanced mail greeting that enables a server to announce support for extended messaging options. The extended messaging modes are discussed in subsequent sections of this document. Compliant implementations MUST implement the ESMTP command and return the capabilities indicated later in this memo. From [ESMTP]
サーバーが拡張メッセージングオプションのサポートをアナウンスできるようにする拡張メールグリーティング。拡張メッセージングモードについては、このドキュメントの以降のセクションで説明します。準拠した実装はESMTPコマンドを実装し、このメモの後半に示されている機能を返す必要があります。 [ESMTP]から
The BDAT command provides a higher efficiency alternative to the earlier DATA command, especially for voice. The BDAT command provides for native binary transport of messages. Compliant implementations SHOULD support binary transport using the BDAT command [BINARY].
BDATコマンドは、特に音声に対して、以前のDATAコマンドに代わるより効率的な方法を提供します。 BDATコマンドは、メッセージのネイティブバイナリトランスポートを提供します。準拠した実装は、BDATコマンド[BINARY]を使用したバイナリ転送をサポートする必要があります（SHOULD）。
The following ESMTP keywords indicate extended features useful for voice messaging.
次のESMTPキーワードは、ボイスメッセージに役立つ拡張機能を示しています。
The "PIPELINING" keyword indicates ability of the receiving server to accept new commands before issuing a response to the previous command. Pipelining commands dramatically improves performance by reducing the number of round-trip packet exchanges and makes it possible to validate all recipient addresses in one operation. Compliant implementations SHOULD support the command pipelining indicated by this keyword. From [PIPE]
「PIPELINING」キーワードは、受信サーバーが前のコマンドへの応答を発行する前に新しいコマンドを受け入れる能力を示します。コマンドをパイプライン化すると、往復のパケット交換の数が減り、パフォーマンスが劇的に向上し、1回の操作ですべての受信者アドレスを検証できるようになります。準拠した実装は、このキーワードで示されるコマンドパイプラインをサポートする必要があります（SHOULD）。 [PIPE]から
The "SIZE" keyword provides a mechanism by which the SMTP server can indicate the maximum size message supported. Compliant servers MUST provide size extension to indicate the maximum size message that can be accepted. Clients SHOULD NOT send messages larger than the size indicated by the server. Clients SHOULD advertise SIZE= when sending messages to servers that indicate support for the SIZE extension. From [SIZE]
「SIZE」キーワードは、SMTPサーバーがサポートされる最大サイズのメッセージを示すことができるメカニズムを提供します。準拠サーバーは、受け入れ可能なメッセージの最大サイズを示すサイズ拡張を提供する必要があります。クライアントは、サーバーが示すサイズよりも大きいメッセージを送信してはなりません。クライアントは、SIZE拡張のサポートを示すメッセージをサーバーに送信するときに、SIZE =を通知する必要があります（SHOULD）。 [サイズ]から
The "CHUNKING" keyword indicates that the receiver will support the high-performance binary transport mode. Note that CHUNKING can be used with any message format and does not imply support for binary encoded messages. Compliant implementations MAY support binary transport indicated by this capability. From [BINARY]
「CHUNKING」キーワードは、レシーバが高性能バイナリトランスポートモードをサポートすることを示します。 CHUNKINGは任意のメッセージフォーマットで使用でき、バイナリエンコードされたメッセージのサポートを意味するものではないことに注意してください。準拠した実装は、この機能によって示されるバイナリ転送をサポートしてもよい（MAY）。 [BINARY]から
The "BINARYMIME" keyword indicates that the SMTP server can accept binary encoded MIME messages. Compliant implementations MAY support binary transport indicated by this capability. Note that support for this feature requires support of CHUNKING. From [BINARY]
「BINARYMIME」キーワードは、SMTPサーバーがバイナリエンコードされたMIMEメッセージを受け入れることができることを示します。準拠した実装は、この機能によって示されるバイナリ転送をサポートしてもよい（MAY）。この機能をサポートするには、CHUNKINGのサポートが必要です。 [BINARY]から
The "DSN" keyword indicates that the SMTP server will accept explicit delivery status notification requests. Compliant implementations MUST support the delivery notification extensions in [DRPT].
「DSN」キーワードは、SMTPサーバーが明示的な配信ステータス通知要求を受け入れることを示します。準拠した実装は、[DRPT]の配信通知拡張をサポートする必要があります。
The "ENHANCEDSTATUSCODES" keyword indicates that an SMTP server augments its responses with the enhanced mail system status codes [CODES]. These codes can then be used to provide more informative explanations of error conditions, especially in the context of the delivery status notifications format defined in [DSN]. Compliant implementations SHOULD support this capability. From [STATUS]
「ENHANCEDSTATUSCODES」キーワードは、SMTPサーバーが拡張メールシステムステータスコード[CODES]で応答を増強することを示します。これらのコードを使用して、特に[DSN]で定義されている配信ステータス通知フォーマットのコンテキストで、エラー状態のより説明的な説明を提供できます。準拠した実装は、この機能をサポートする必要があります（SHOULD）。 [ステータス]から
The current message is a binary encoded MIME messages. Compliant implementations SHOULD support binary transport indicated by this parameter. From [BINARY]
現在のメッセージは、バイナリエンコードされたMIMEメッセージです。準拠した実装は、このパラメータで示されるバイナリ転送をサポートする必要があります（SHOULD）。 [BINARY]から
The RET parameter indicates whether the content of the message should be returned. Compliant systems SHOULD honor a request for returned content. From [DRPT]
RETパラメータは、メッセージのコンテンツを返すかどうかを示します。準拠システムは、返されたコンテンツのリクエストを尊重する必要があります。 [DRPT]から
The ENVID keyword of the SMTP MAIL command is used to specify an "envelope identifier" to be transmitted along with the message and included in any DSNs issued for any of the recipients named in this SMTP transaction. The purpose of the envelope identifier is to allow the sender of a message to identify the transaction for which the DSN was issued. Compliant implementations MAY use this parameter. From [DRPT]
SMTP MAILコマンドのENVIDキーワードを使用して、メッセージと共に送信され、このSMTPトランザクションで指定された受信者のいずれかに対して発行されたDSNに含まれる「エンベロープ識別子」を指定します。エンベロープ識別子の目的は、メッセージの送信者がDSNが発行されたトランザクションを識別できるようにすることです。準拠した実装はこのパラメータを使用してもよい（MAY）。 [DRPT]から
The NOTIFY parameter indicates the conditions under which a delivery report should be sent. Compliant implementations MUST honor this request. From [DRPT]
NOTIFYパラメータは、配信レポートが送信される条件を示します。準拠した実装では、この要求を尊重する必要があります。 [DRPT]から
The ORCPT keyword of the RCPT command is used to specify an "original" recipient address that corresponds to the actual recipient to which the message is to be delivered. If the ORCPT esmtp-keyword is used, it MUST have an associated esmtp-value, which consists of the original recipient address, encoded according to the rules below. Compliant implementations MAY use this parameter. From [DRPT]
RCPTコマンドのORCPTキーワードは、メッセージが配信される実際の受信者に対応する「元の」受信者アドレスを指定するために使用されます。 ORCPT esmtp-keywordを使用する場合は、以下のルールに従ってエンコードされた、元の受信者アドレスで構成される関連するesmtp-valueが必要です。準拠した実装はこのパラメータを使用してもよい（MAY）。 [DRPT]から
The ESMTP extensions suggested or required for conformance to VPIM fall into two categories. The first category includes features which 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への適合のために提案または必要とされるESMTP拡張は、2つのカテゴリに分類されます。最初のカテゴリには、SIZE、BINARYMIME、PIPELININGなどのトランスポートシステムの効率を高める機能が含まれています。機能の低いトランスポートシステムにダウングレードした場合、これらの機能は送信者または受信者の機能を変更せずに削除できます。
The second category of features are 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 compliant ESMTP support the ESMTP 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 positive delivery status notification. It is RECOMMENDED that the downgrading system should continue to attempt to deliver the message, but MUST send an appropriate delivery notification to the originator, e.g. the message left an ESMTP host and was sent (unreliably) via SMTP.
機能の2番目のカテゴリは、新機能をサポートするトランスポート拡張です。 DSNおよびEnhancedStatusCodesは、配信ステータス通知の処理に本質的な改善を提供し、ボイスメールに期待される信頼性のレベルに電子メールをもたらします。イントラネットまたはグローバルインターネット全体で一貫したサービスレベルを確保するには、VPIM発信システムと受信者システム間のすべてのホップで、VPIM準拠のESMTPがESMTP DSN拡張をサポートすることが不可欠です。 「ダウングレード」が避けられない状況では、ポジティブ配信ステータス通知のESMTP要求なしで、リレーホップが（ネクストホップによって）強制的にVPIMメッセージを転送する場合があります。ダウングレードシステムは引き続きメッセージの配信を試行する必要がありますが、適切な配信通知を発信者に送信する必要があります。メッセージはESMTPホストから送信され、SMTP経由で（信頼性のない方法で）送信されました。
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 offered only a telephone user interface. The mapping of the dialed target number to a routeable FQDN address allowing delivery to the destination system can be accomplished through implementation-specific means.
ユーザーが入力したアドレスに基づいて受信者の完全修飾ドメイン名（FQDN）を提供するのはVPIMシステムの責任です（入力したアドレスがまだFQDNでない場合）。これは通常、電話ユーザーインターフェイスのみを提供するシステムの問題です。ダイヤルされたターゲット番号のルーティング可能なFQDNアドレスへのマッピングは、宛先システムへの配信を可能にするため、実装固有の方法で実行できます。
To facilitate a local dial-by-name cache, an implementation may wish to populate local directories with the first and last names, as well as the address information extracted from received messages. It is mandated that only address information from vCard attachments to VPIM messages be used to populate such a directory when the vCard is available. Addresses or names parsed from the header fields of VPIM messages SHOULD NOT be used to populate directories as it only provides partial data. Alternatively, bilateral agreements could be made to allow the bulk transfer of vCards between systems.
ローカルの名前によるダイヤルキャッシュを容易にするために、実装では、ローカルディレクトリに姓名、および受信したメッセージから抽出されたアドレス情報を入力できます。 vCardが使用可能な場合は、vCard添付ファイルからVPIMメッセージへのアドレス情報のみを使用して、このようなディレクトリに入力する必要があります。 VPIMメッセージのヘッダーフィールドから解析されたアドレスまたは名前は、部分的なデータしか提供しないため、ディレクトリへの入力には使用しないでください。または、システム間のvCardの一括転送を許可するための二国間協定を結ぶこともできます。
The use of client/server desktop mailbox protocols like IMAP or POP to retrieve VPIM messages from a IMAP or POP message store is possible without any special modifications to this VPIM specification. Email clients (and web browsers) typically have a table for mapping from MIME type to displaying application. The audio/*, image/tiff and text/directory contents can be configured so that they invoke the correct player/recorder for rendering. In addition with IMAP clients, the first multipart/mixed content (if present) will not appear since it is a generic part. The user instead will be presented with a message that has (for example) audio and image contents.
IMAPやPOPなどのクライアント/サーバーデスクトップメールボックスプロトコルを使用して、IMAPまたはPOPメッセージストアからVPIMメッセージを取得することは、このVPIM仕様に特別な変更を加えなくても可能です。電子メールクライアント（およびWebブラウザー）には、通常、MIMEタイプから表示アプリケーションにマッピングするためのテーブルがあります。 audio / *、image / tiffおよびtext / directoryの内容は、レンダリングのために正しいプレーヤー/レコーダーを呼び出すように構成できます。さらに、IMAPクライアントでは、最初のmultipart / mixedコンテンツ（存在する場合）は汎用パーツであるため表示されません。代わりに、ユーザーには（たとえば）オーディオとイメージのコンテンツを含むメッセージが表示されます。
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 compliant message machine.
インターネットプロトコルは、物理ネットワークの管理からメッセージキューの管理まで、メッセージングシステムの管理のためのメカニズムを提供します。 SNMPは、準拠メッセージマシンでサポートされている必要があります。
The digital interface to the VM and the TCP/IP protocols MAY be managed. MIB II MAY be implemented to provide basic statistics and reporting of TCP and IP protocol performance [MIB II].
VMへのデジタルインターフェイスとTCP / IPプロトコルは管理される場合があります。 MIB IIは、TCPおよびIPプロトコルのパフォーマンスの基本的な統計およびレポートを提供するために実装される場合があります[MIB II]。
VPIM is a messaging application which must be supported in several environments and be supported on differing devices. These environments include traditional voice processing systems, desktop voice messaging systems, store and forward relays, and protocol translation gateways.
VPIMは、いくつかの環境でサポートされ、さまざまなデバイスでサポートされる必要があるメッセージングアプリケーションです。これらの環境には、従来の音声処理システム、デスクトップボイスメッセージングシステム、ストアアンドフォワードリレー、プロトコル変換ゲートウェイが含まれます。
In order to accommodate all environments, this document defines two areas of conformance: transport and content.
すべての環境に対応するために、このドキュメントでは、トランスポートとコンテンツという2つの適合領域を定義しています。
Transport conformant systems will pass VPIM messages in a store and forward manner with assured delivery notifications and without the loss of information. It is expected that most store and forward Internet mail based messaging systems will be VPIM transport compliant.
トランスポート準拠システムは、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 compliance requirements is contained in Appendix A.
コンプライアンス要件の概要は、付録Aに含まれています。
VPIM end systems are expected to be both transport and content conformant. They should generate conforming content, reliably send it to the next hop system, receive a message, decode the message and present it to the user. Voice messaging systems and protocol conversion gateways are considered end systems.
VPIMエンドシステムは、トランスポートとコンテンツの両方に適合することが期待されています。彼らは適合コンテンツを生成し、それを確実にネクストホップシステムに送信し、メッセージを受信し、メッセージをデコードしてユーザーに提示する必要があります。ボイスメッセージシステムとプロトコル変換ゲートウェイは、エンドシステムと見なされます。
Relay systems are expected to be transport compliant 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 and are expected to be content conformant. Desktop email clients use various protocols and API's for exchanging messages with the local message store and message transport system. While these clients may benefit from VPIM transport capabilities, specific client-server requirements are out-of-scope for this document.
VPIMをサポートし、コンテンツ適合性が期待されるデスクトップ電子メールクライアント。デスクトップ電子メールクライアントは、ローカルメッセージストアおよびメッセージ転送システムとメッセージを交換するために、さまざまなプロトコルとAPIを使用します。これらのクライアントはVPIMトランスポート機能の恩恵を受ける可能性がありますが、特定のクライアント/サーバー要件はこのドキュメントの範囲外です。
This document is a profile of existing Internet mail protocols. To maintain interoperability with Internet mail, any security to be provided should be part of the of the Internet security infrastructure, rather than a new mechanism or some other mechanism outside of the Internet infrastructure.
このドキュメントは、既存のインターネットメールプロトコルのプロファイルです。インターネットメールとの相互運用性を維持するには、提供するセキュリティを、インターネットインフラストラクチャの外部にある新しいメカニズムやその他のメカニズムではなく、インターネットセキュリティインフラストラクチャの一部にする必要があります。
Both Internet mail and voice messaging have their own set of threats and countermeasures. As such, this specification does not create any security issues not already existing in the profiled Internet mail and voice mail protocols themselves. This section attends only to the set of additional threats which ensue from integrating the two services.
インターネットメールとボイスメッセージには、それぞれ独自の脅威と対策があります。そのため、この仕様では、プロファイルされたインターネットメールおよびボイスメールプロトコル自体にはまだ存在しないセキュリティの問題は発生しません。このセクションでは、2つのサービスの統合により発生する一連の追加の脅威についてのみ説明します。
The actual sender of the voice message might not be the same as that specified in the Sender or From header fields of the message content 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 senders 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.
音声メッセージの実際の送信者は、メッセージコンテンツヘッダーフィールドのSenderまたはFromヘッダーフィールド、またはSMTPエンベロープからのMAIL FROMアドレスで指定されたものとは異なる場合があります。厳しく制約された環境では、十分な物理的およびソフトウェア制御により、この問題を確実に防止できる場合があります。さらに、送信者の声の認識は、SenderまたはFromで指定されたものに関係なく、送信者のIDの信頼性を提供します。 SMTP実装は、メッセージの送信者に固有の認証を提供せず、サイトがそのような認証を提供する義務を負っていないことを認識してください。
Assigning an Internet mail address to a voice mailbox opens the possibility of receiving unsolicited messages (either text or voice mail). Traditionally voice mail systems operated in closed environments and were not susceptible to unknown senders. Voice mail users have a higher expectation of mailbox privacy and may consider such messages as a security breach. Many Internet mail systems are choosing to block all messages from unknown sources in an attempt to curb this problem.
インターネットメールアドレスをボイスメールボックスに割り当てると、迷惑メッセージ（テキストまたはボイスメール）を受信する可能性が広がります。従来、ボイスメールシステムは閉じた環境で動作し、不明な送信者の影響を受けませんでした。ボイスメールユーザーは、メールボックスのプライバシーに対する期待が高く、そのようなメッセージをセキュリティ違反と見なす場合があります。多くのインターネットメールシステムは、この問題を抑制するために、不明なソースからのすべてのメッセージをブロックすることを選択しています。
Users of voice messaging systems have an expectation of a level of message privacy which is higher than the level provided by Internet mail without security enhancements. This expectation of privacy by users SHOULD be preserved as much as possible.
ボイスメッセージングシステムのユーザーは、セキュリティが強化されていないインターネットメールで提供されるレベルよりも高いレベルのメッセージプライバシーを期待しています。ユーザーによるプライバシーのこの期待は、可能な限り維持されるべきです。
Sufficient physical and software control may be acceptable in constrained environments. Further, the profile specified in this document does not in any way preclude the use of any Internet object or channel security protocol to encrypt, authenticate, or non-repudiate the messages.
制約のある環境では、十分な物理的およびソフトウェア制御が許容される場合があります。さらに、このドキュメントで指定されているプロファイルは、メッセージの暗号化、認証、または否認防止のためのインターネットオブジェクトまたはチャネルセキュリティプロトコルの使用を決して排除するものではありません。
[8BIT] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. Crocker, "SMTP Service Extension for 8bit-MIMEtransport", RFC 1426, February 1993.
[8BIT] Klensin、J.、Freed、N.、Rose、M.、Stefferud、E。、およびD. Crocker、「8bit-MIMEtransportのSMTPサービス拡張」、RFC 1426、1993年2月。
[ADPCM] Vaudreuil, G., and G. Parsons, "Toll Quality Voice - 32 kbit/s ADPCM: MIME Sub-type Registration", RFC 2422, September 1998.
[ADPCM] Vaudreuil、G。、およびG. Parsons、「Toll Quality Voice-32 kbit / s ADPCM：MIME Sub-type Registration」、RFC 2422、1998年9月。
[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、1993年8月3日。
[BINARY] Vaudreuil, G., "SMTP Service Extensions for Transmission of Large and Binary MIME Messages", RFC 1830, October 1995.
[BINARY] Vaudreuil、G。、「SMTP Service Extensions for Transmission of Large and Binary MIME Messages」、RFC 1830、1995年10月。
[CODES] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 1893, January 1996.
[コード] Vaudreuil、G。、「Enhanced Mail System Status Codes」、RFC 1893、1996年1月。
[MIMEDIR] Howes, T., Smith, M., and F. Dawson, "A MIME Content-Type for Directory Information", RFC 2425, September 1998.
[MIMEDIR]ハウズ、T。、スミス、M。、およびF.ドーソン、「ディレクトリ情報用のMIMEコンテンツタイプ」、RFC 2425、1998年9月。
[DISP] Troost, R., and S. Dorner, "Communicating Presentation Information in Internet Messages: The Content-Disposition Header", RFC 2183, August 1997.
[DISP] Troost、R。、およびS. Dorner、「Communicating Presentation Information in Internet Messages：The Content-Disposition Header」、RFC 2183、1997年8月。
[DNS1] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[DNS1] Mockapetris、P。、「ドメイン名-実装と仕様」、STD 13、RFC 1035、1987年11月。
[DNS2] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[DNS2] Mockapetris、P。、「ドメイン名-概念と機能」、STD 13、RFC 1034、1987年11月。
[DRPT] Moore, K., "SMTP Service Extensions for Delivery Status Notifications", RFC 1891, January 1996.
[DRPT] Moore、K。、「SMTP Service Extensions for Delivery Status Notifications」、RFC 1891、1996年1月。
[DSN] Moore, K., and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 1894, January 1996.
[DSN] Moore、K。、およびG. Vaudreuil、「配信ステータス通知の拡張可能なメッセージ形式」、RFC 1894、1996年1月。
[DUR] Vaudreuil, G., and G. Parsons, "Content Duration MIME Header Definition", RFC 2424, September 1998.
[DUR] Vaudreuil、G。、およびG. Parsons、「コンテンツ期間MIMEヘッダー定義」、RFC 2424、1998年9月。
[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., Freed, N., Rose, M., Stefferud, E., and D. Crocker, "SMTP Service Extensions", RFC 1869, November 1995.
[ESMTP] Klensin、J.、Freed、N.、Rose、M.、Stefferud、E。、およびD. Crocker、「SMTP Service Extensions」、RFC 1869、1995年11月。
[G726] CCITT Recommendation G.726 (1990), General Aspects of Digital Transmission Systems, Terminal Equipment - 40, 32, 24,16 kbit/s Adaptive Differential Pulse Code Modulation (ADPCM).
[G726] CCITT勧告G.726（1990）、デジタル伝送システムの一般的な側面、端末装置-40、32、24、16 kbit / s適応差動パルス符号変調（ADPCM）。
[HOSTREQ] Braden, R., "Requirements for Internet Hosts -- Application and Support", STD 3, RFC 1123, October 1989.
[HOSTREQ] Braden、R。、「インターネットホストの要件-アプリケーションとサポート」、STD 3、RFC 1123、1989年10月。
[LANG] Alvestrand, H., "Tags for the Identification of Languages", RFC 1766, March 1995.
[LANG] Alvestrand、H。、「言語の識別のためのタグ」、RFC 1766、1995年3月。
[MDN] Fajman, R., "An Extensible Message Format for Message Disposition Notifications", RFC 2298, March 1998.
[MDN] Fajman、R。、「メッセージ処理通知の拡張可能なメッセージ形式」、RFC 2298、1998年3月。
[MIB II] Rose, M., "Management Information Base for Network Management of TCP/IP-based internets: MIB-II", RFC 1158, May 1990.
[MIB II] Rose、M。、「TCP / IPベースのインターネットのネットワーク管理のための管理情報ベース：MIB-II」、RFC 1158、1990年5月。
[MIME1] Freed, N., and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[MIME1] Freed、N。、およびN. Borenstein、「Multipurpose Internet Mail Extensions（MIME）Part One：Format of Internet Message Bodies」、RFC 2045、1996年11月。
[MIME2] Freed, N., and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[MIME2] Freed、N。、およびN. Borenstein、「Multipurpose Internet Mail Extensions（MIME）Part Two：Media Types」、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] Freed、N.、Klensin、J。、およびJ. Postel、「Multipurpose Internet Mail Extensions（MIME）Part Four：Registration Procedures」、RFC 2048、1996年11月。
[MIME5] Freed, N., and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 2049, November 1996.
[MIME5] Freed、N。、およびN. Borenstein、「Multipurpose Internet Mail Extensions（MIME）Part 5：Conformance Criteria and Examples」、RFC 2049、1996年11月。
[PIPE] Freed, N., and A. Cargille, "SMTP Service Extension for Command Pipelining", RFC 1854, October 1995.
[パイプ] Freed、N。、およびA. Cargille、「SMTP Service Extension for Command Pipelining」、RFC 1854、1995年10月。
[REPORT] Vaudreuil, G., "The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages", RFC 1892, January 1996.
[レポート] Vaudreuil、G。、「メールシステム管理メッセージのレポートのマルチパート/レポートコンテンツタイプ」、RFC 1892、1996年1月。
[REQ] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[REQ] Bradner、S.、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC822] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, August 1982.
[RFC822] Crocker、D。、「ARPAインターネットテキストメッセージのフォーマットの標準」、STD 11、RFC 822、1982年8月。
[SIZE] Klensin, J., Freed, N., and K. Moore, "SMTP Service Extensions for Message Size Declaration", RFC 1870, November 1995.
[サイズ] Klensin、J.、Freed、N。、およびK. Moore、「メッセージサイズ宣言のためのSMTPサービス拡張」、RFC 1870、1995年11月。
[SMTP] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.
[SMTP] Postel、J。、「Simple Mail Transfer Protocol」、STD 10、RFC 821、1982年8月。
[STATUS] Freed, N., "SMTP Service Extension for Returning Enhanced Error Codes", RFC 2034, October 1996.
[ステータス] Freed、N。、「拡張エラーコードを返すためのSMTPサービス拡張」、RFC 2034、1996年10月。
[TIFF-F] Parsons, G., and J. Rafferty, "Tag Image File Format: Application F", RFC 2306, March 1998.
[TIFF-F]パーソンズ、G、およびJ.ラファティ、「タグ画像ファイル形式：アプリケーションF」、RFC 2306、1998年3月。
[TIFFREG] Parsons, G., Rafferty, J., and S. Zilles, "Tag Image File Format: image/tiff - MIME sub-type registraion", RFC 2302, March 1998.
[TIFFREG] Parsons、G.、Rafferty、J。、およびS. Zilles、「Tag Image File Format：image / tiff-MIME sub-type registraion」、RFC 2302、1998年3月。
[V-MSG] Vaudreuil, G., and G. Parsons, "VPIM Voice Message: MIME Sub-type Registration", RFC 2423, September 1998.
[V-MSG] Vaudreuil、G。、およびG. Parsons、「VPIM Voice Message：MIME Sub-type Registration」、RFC 2423、1998年9月。
[VCARD] Dawson, F., and T. Howes, "vCard MIME Directory Profile", RFC 2426, September 1998.
[VCARD] Dawson、F。、およびT. Howes、「vCard MIME Directory Profile」、RFC 2426、1998年9月。
[VPIM1] Vaudreuil, G., "Voice Profile for Internet Mail", RFC 1911, February 1996.
[VPIM1] Vaudreuil、G。、「Voice Profile for Internet Mail」、RFC 1911、1996年2月。
[X.400] Hardcastle-Kille, S., "Mapping between X.400(1988) / ISO 10021 and RFC 822", RFC 1327, May 1992.
[X.400] Hardcastle-Kille、S。、「X.400（1988）/ ISO 10021とRFC 822の間のマッピング」、RFC 1327、1992年5月。
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 VPIM Work Group, for their support of the VPIM specification and the efforts they have made to ensure its success.
著者は、VPIM仕様のサポートと、その成功を確実にするために行った努力について、Electronic Messaging Association（EMA）、特にボイスメッセージング委員会とVPIMワークグループのメンバーに特に感謝したいと思います。
The EMA hosts the VPIM web page at http://www.ema.org/vpim.
EMAは、http：//www.ema.org/vpimでVPIM Webページをホストします。
Glenn W. Parsons Northern Telecom P.O. Box 3511, Station C Ottawa, ON K1Y 4H7 Canada
グレンW.パーソンズノーザンテレコムP.O. Box 3511、ステーションCオタワ、オンK1Y 4H7カナダ
Phone: +1-613-763-7582
Fax: +1-613-763-4461
EMail: Glenn.Parsons@Nortel.ca
Gregory M. Vaudreuil Lucent Technologies, Octel Messaging Division 17080 Dallas Parkway Dallas, TX 75248-1905 United States
Gregory M. Vaudreuil Lucent Technologies、Octel Messaging Division 17080ダラスパークウェイダラス、テキサス州75248-1905アメリカ合衆国
Phone/Fax: +1-972-733-2722
EMail: GregV@Lucent.Com
The following table summarizes the profile of VPIM version 2 detailed in this document. Since in many cases it is not possible to simplify the qualifications for supporting each feature this appendix is informative. The reader is recommended to read the complete explanation of each feature in the referenced section. The text in the previous sections shall be deemed authoritative if any item in this table is ambiguous.
次の表は、このドキュメントで説明されているVPIMバージョン2のプロファイルをまとめたものです。多くの場合、各機能をサポートするための資格を単純化することは不可能であるため、この付録は参考情報です。参照セクションの各機能の完全な説明を読むことをお勧めします。前のセクションのテキストは、この表のいずれかの項目があいまいな場合に、信頼できるものと見なされます。
The conformance table is separated into various columns:
適合表はさまざまな列に分かれています。
Feature - name of protocol feature (note that the indenting indicates a hierarchy of conformance, i.e. the conformance of a lower feature is only relevant if there is conformance to the higher feature)
機能-プロトコル機能の名前（インデントは適合の階層を示すことに注意してください。つまり、下位の機能の適合は、上位の機能への適合がある場合にのみ関連します）
Section - reference section in main text of this document
セクション-このドキュメントの本文の参照セクション
Area - conformance area to which each feature applies: C - content T - transport
エリア-各機能が適用される適合エリア：C-コンテンツT-トランスポート
Status - whether the feature is mandatory, optional, or prohibited. The key words used in this table are to be interpreted as described in [REQ], though the following list gives a quick overview of the different degrees of feature conformance: 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
ステータス-機能が必須、オプション、禁止のいずれであるか。この表で使用されているキーワードは、[REQ]で説明されているように解釈されますが、次のリストは、さまざまな程度の機能適合の概要を簡単に示しています。 5月-オプション-すべきではない-やむを得ないニーズがない場合は禁止。してはいけない-禁止
Footnote - special comment about conformance for a particular feature
脚注-特定の機能への適合に関する特別なコメント
VPIM version 2 Conformance
| | | | |S| |
| | | | | |H| |F
| | | | | |O|M|o
| | | |S| |U|U|o
| | | |H| |L|S|t
| |A|M|O| |D|T|n
| |R|U|U|M| | |o
| |E|S|L|A|N|N|t
| |A|T|D|Y|O|O|t
FEATURE |SECTION | | | | |T|T|e
-------------------------------------------|----------|-|-|-|-|-|-|-
| | | | | | | |
Message Addressing Formats: | | | | | | | |
Use DNS host names |4.1 |C|x| | | | |
Use only numbers in mailbox IDs |4.1.1 |C| |x| | | |
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: | | | | | | | |
Encoding outbound messages | | | | | | | |
From |4.2.1 |C|x| | | | |
Addition of text name |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.2.16 |C| | |x| | |
Disposition-notification-options |4.2.17 |C| | |x| | |
Other Headers |4.2 |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
-------------------------------------------|----------|-|-|-|-|-|-|-
Detection & Decoding 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| | | | |
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.2.16 |C| | |x| | |
Disposition-notification-options |4.2.17 |C| | |x| | |
Other Headers |4.2 |C|x| | | | |3
| | | | | | | |
Message Content Encoding: | | | | | | | |
Encoding outbound audio/fax contents | | | | | | | |
7BIT |4.3 |C| | | | |x|
8BIT |4.3 |C| | | | |x|
Quoted Printable |4.3 |C| | | | |x|
Base64 |4.3 |C|x| | | | |4
Binary |4.3 |C| |x| | | |5
Detection & decoding inbound messages | | | | | | | |
7BIT |4.3 |C|x| | | | |
8BIT |4.3 |C|x| | | | |
Quoted Printable |4.3 |C|x| | | | |
Base64 |4.3 |C|x| | | | |
Binary |4.3 |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: | | | | | | | |
Inclusion in outbound messages | | | | | | | |
Multipart/Voice-Message |4.3.1 |C|x| | | | |
Message/RFC822 |4.3.2 |C| | |x| | |
Text/Directory |4.3.3 |C| |x| | | |
include TEL, EMAIL, VERSION |4.3.3 |C|x| | | | |
include ROLE, SOUND, N, REV |4.3.3 |C| |x| | | |
only one voice type per level |4.3.3 |C|x| | | | |
Audio/32KADPCM |4.3.4 |C|x| | | | |
Content-Description |4.3.4.1 |C| | |x| | |
Content-Disposition |4.3.4.2 |C|x| | | | |
Content-Duration |4.3.4.3 |C| | |x| | |
Content-Langauge |4.3.4.4 |C| | |x| | |
Image/tiff; application=faxbw |4.3.5 |C| | |x| | |
Audio/* or Image/* (other encodings) |4.3.6 |C| | |x| | |
Multipart/Mixed |4.4.1 |C| | |x| | |
Text/plain |4.4.2 |C| | | |x| |
Multipart/Report |4.4.3 |C|x| | | | |
human-readable part is voice |4.4.3 |C| |x| | | |
human-readable part is text |4.4.3 |C| | |x| | |
Message/delivery-status |4.4.4 |C|x| | | | |
Message/disposition-notification |4.4.5 |C| |x| | | |
Other contents |4.4 |C| | | |x| |6
| | | | | | | |
Detection & decoding in inbound messages | | | | | | | |
Multipart/Voice-Message |4.3.1 |C|x| | | | |
Message/RFC822 |4.3.2 |C|x| | | | |
Text/Directory |4.3.3 |C| |x| | | |
recognize TEL, EMAIL, VERSION |4.3.3 |C|x| | | | |
recognize ROLE, SOUND, N, REV |4.3.3 |C| |x| | | |
Audio/32KADPCM |4.3.4 |C|x| | | | |
Content-Description |4.3.4.1 |C| | |x| | |
Content-Disposition |4.3.4.2 |C| |x| | | |
Content-Duration |4.3.4.3 |C| | |x| | |
Content-Langauge |4.3.4.4 |C| | |x| | |
Image/tiff; application=faxbw |4.3.5 |C| |x| | | |
send NDN if unable to render |4.3.5 |C|x| | | | |7
Audio/* or Image/* (other encodings) |4.3.6 |C| | |x| | |
Multipart/Mixed |4.4.1 |C|x| | | | |
Text/plain |4.4.2 |C|x| | | | |
send NDN if unable to render |4.4.2 |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
------------------------------------------|-----------|-|-|-|-|-|-|-
| | | | | | | |
Multipart/Report |4.4.3 |C|x| | | | |
human-readable part is voice |4.4.3 |C| |x| | | |
human-readable part is text |4.4.3 |C|x| | | | |
Message/delivery-status |4.4.4 |C|x| | | | |
Message/disposition-notification |4.4.5 |C| |x| | | |
Other contents |4.4 |C| | | |x| |6
send NDN if unable to render |4.4 |C| |x| | | |
| | | | | | | |
Forwarded Messages | | | | | | | |
use Message/RFC822 construct |4.5 |C| |x| | | |
simulate headers if none available |4.5 |C| |x| | | |
| | | | | | | |
Reply Messages | | | | | | | |
send to Reply-to, else From address |4.6 |C|x| | | | |
do not send to non-mail-user |4.6 |C|x| | | | |
| | | | | | | |
Notifications | | | | | | | |
use multipart/report format |4.7 |C|x| | | | |
always send error on non-delivery |4.7 |C| |x| | | |
| | | | | | | |
Message Transport Protocol: | | | | | | | |
ESMTP Commands | | | | | | | |
HELO |5.1.1 |T|x| | | | |
MAIL FROM |5.1.2 |T|x| | | | |
support null address |5.1.2 |T|x| | | | |
RCPT TO |5.1.3 |T|x| | | | |
DATA |5.1.4 |T|x| | | | |
TURN |5.1.5 |T| | | | |x|
QUIT |5.1.6 |T|x| | | | |
RSET |5.1.7 |T|x| | | | |
VRFY |5.1.8 |T| | |x| | |
EHLO |5.1.9 |T|x| | | | |
BDAT |5.1.10 |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 | | | | | | | |
PIPELINING |5.2.1 |T| |x| | | |
SIZE |5.2.2 |T|x| | | | |
CHUNKING |5.2.3 |T| | |x| | |
BINARYMIME |5.2.4,5.3.1|T| | |x| | |
DSN |5.2.5 |T|x| | | | |
ENHANCEDSTATUSCODES |5.2.6 |T| |x| | | |
RET |5.3.2 |T| |x| | | |
ENVID |5.3.3 |T| | |x| | |
NOTIFY |5.4.1 |T|x| | | | |
ORCPT |5.4.2 |T| | |x| | |
| | | | | | | |
ESMTP-SMTP Downgrading | | | | | | | |
send delivery report upon downgrade |
| | | | | | | |
Directory Address Resolution | | | | | | | |
provide facility to resolve addresses |6 |C| |x| | | |
use vCards to populate local directory |6 |C| |x| | | |8
use headers to populate local directory |6 |C| | | |x| |
| | | | | | | |
Management Protocols: | | | | | | | |
Network management |8.1 |T| ||x| | |
-------------------------------------------|----------|-|-|-|-|-|-|-
Footnotes:
脚注：
1. MUST NOT include 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 addtional header fields are not understood they MAY be ignored 4. When binary transport is not available 5. When binary transport is available 6. Other un-profiled contents must only be sent by bilateral agreement. 7. If the content cannot be presented in some form, the entire message MUST be returned with a negative delivery status notification. 8. When the vCard is present in a message
1.すべての受信者が不明または解決できない場合は含めないでください。 2.機密メッセージが機密性をサポートしないシステムによって受信された場合、適切なエラー通知とともに発信者に返さなければなりません（MUST）。また、受信した機密メッセージを誰にも転送しないでください。 3.追加のヘッダーフィールドが理解されない場合、それらは無視される可能性があります。4。バイナリトランスポートが利用できない場合7.コンテンツを何らかの形で提示できない場合は、メッセージ全体を否定的な配信ステータス通知とともに返さなければなりません。 8. vCardがメッセージに含まれている場合
The following message is a full-featured message addressed to two recipients. The message includes the sender's spoken name and a short speech segment. The message is marked as important and private.
次のメッセージは、2人の受信者宛てのフル機能のメッセージです。メッセージには、送信者の音声名と短い音声セグメントが含まれています。メッセージは重要かつ非公開としてマークされています。
To: +19725551212@vm1.mycompany.com
To: +16135551234@VM1.mycompany.com
From: "Parsons, Glenn" <12145551234@VM2.mycompany.com>
Date: Mon, 26 Aug 93 10:20:20 -0700 (CDT)
MIME-Version: 1.0 (Voice 2.0)
Content-type: Multipart/Voice-Message; Version=2.0;
Boundary="MessageBoundary"
Content-Transfer-Encoding: 7bit
Message-ID: 123456789@VM2.mycompany.com
Sensitivity: Private
Importance: High
--MessageBoundary
Content-type: Audio/32KADPCM
Content-Transfer-Encoding: Base64
Content-Disposition: inline; voice=Originator-Spoken-Name
Content-Language: en-US
Content-ID: part1@VM2-4321
glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd (This is a sample of the base-64 Spoken Name data) fgdhgddlkgpokpeowrit09==
glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd（これはbase-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
iIiIiIjMzN3czdze3s7d7fwfHhcvESJVe/4yEhLz8/FOQjVFRERCESL/zqrq
(This is a sample of the base64 message data) zb8tFdLTQt1PXj
u7wjOyRhws+krdns7Rju0t4tLF7cE0K0MxOTOnRW/Pn30c8uHi9==
--MessageBoundary
Content-type: text/directory; charset=us-ascii; profile=vCard
Content-Transfer-Encoding: 7bit
BEGIN:VCARD
N:Parsons;Glenn;;Mr.;
EMAIL;TYPE=INTERNET:+12145551234@VM2.mycompany.com
TEL:+1-217-555-1234
SOUND;TYPE=32KADPCM;ENCODING=URI: CID:<part1@VM2-4321>
REV:19951031T222710Z
VERSION: 3.0
END:VCARD
--MessageBoundary_
--MessageBoundary_
The following message is a forwarded single segment voice. Both the forwarded message and the forwarding message contain VCARDs with spoken names.
次のメッセージは、転送された単一セグメントの音声です。転送されたメッセージと転送されたメッセージの両方に、読み上げられた名前のVCARDが含まれています。
To: +12145551212@vm1.mycompany.com
From: "Vaudreuil, Greg" <+19725552345@VM2.mycompany.com>
Date: Mon, 26 Aug 93 10:20:20 -0700 (CDT)
MIME-Version: 1.0 (Voice 2.0)
Content-type: Multipart/Voice-Message; Version=2.0;
Boundary="MessageBoundary"
Content-Transfer-Encoding: 7bit
Message-ID: ABCD-123456789@VM2.mycompany.com
--MessageBoundary
Content-type: Audio/32KADPCM
Content-Transfer-Encoding: Base64
Content-Disposition: inline; voice=Originator-Spoken-Name
Content-Language: en-US
Content-ID: part3@VM2-4321
glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd (This is a sample of the base-64 Spoken Name data) fgdhgd dlkgpokpeowrit09==
glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd（これはbase-64音声名データのサンプルです）fgdhgd dlkgpokpeowrit09 ==
--MessageBoundary
Content-type: Audio/32KADPCM
Content-Description: Forwarded Message Annotation
Content-Disposition: inline; voice=Voice-Message
Content-Transfer-Encoding: Base64
glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd (This is the voiced introductory remarks encoded in base64) jrgoij3o45itj09fiuvdkjgWlakgQ93ijkpokfpgokQ90gQ5tkjpokfgW dlkgpokpeowrit09==
glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd（これは、base64でエンコードされた有声導入コメントです）jrgoij3o45itj09fiuvdkjgWlakgQ93ijkpokfpgokQ90gQ5tkjpokfritW dlkgpokpepe
--MessageBoundary Content-type: Message/RFC822 Content-Transfer-Encoding: 7bit
--MessageBoundary Content-type：Message / RFC822 Content-Transfer-Encoding：7bit
To: +19725552345@VM2.mycompany.com
From: "Parsons, Glenn, W." <+16135551234@VM1.mycompany.com>
Date: Mon, 26 Aug 93 8:23:10 -0500 (EST)
Content-type: Multipart/Voice-Message; Version=2.0;
Boundary="MessageBoundary2"
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0 (Voice 2.0)
--MessageBoundary2
Content-type: Audio/32KADPCM
Content-Transfer-Encoding: Base64
Content-Disposition: inline; voice=Originator-Spoken-Name
Content-Language: en-US
Content-ID: part6@VM2-4321
glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd (This is a sample of the base-64 Spoken Name data) fgdhgd dlkgpokpeowrit09==
glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd（これはbase-64音声名データのサンプルです）fgdhgd dlkgpokpeowrit09 ==
--MessageBoundary2
Content-type: Audio/32KADPCM
Content-Disposition: inline; voice=Voice-Message
Content-Transfer-Encoding: Base64
glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd (This is the original message audio data) fgwersdfmniwrjj jrgoij3o45itj09fiuvdkjgWlakgQ93ijkpokfpgokQ90gQ5tkjpokfgW dlkgpokpeowrit09==
glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd（これは元のメッセージオーディオデータです）fgwersdfmniwrjj jrgoij3o45itj09fiuvdkjgWlakgQ93ijkpokfpgokQ90gQ5tkjpokfowW dlkgpokpeow
--MessageBoundary2
Content-type: text/directory; charset=us-ascii
Content-Transfer-Encoding: 7bit
BEGIN:VCARD
N:Parsons;Glenn;W;Mr.;
EMAIL;TYPE=INTERNET:+16135551234@VM2.mycompany.com
TEL:+1-613-555-1234
SOUND;TYPE=32KADPCM;ENCODING=URI: CID:<part6@VM2-4321>
REV:19951031T222710Z
END:VCARD
--MessageBoundary2--
--MessageBoundary2--
--MessageBoundary
Content-type: text/directory; charset=us-ascii
Content-Transfer-Encoding: 7bit
BEGIN:VCARD
N:Vaudreuil;Greg;;Mr.;
SOUND;TYPE=32KADPCM;ENCODING=URI: CID:<part3@VM2-4321>
EMAIL;TYPE=INTERNET,VPIM:+19725552345@VM2.mycompany.com
TEL:+1-972-555-2345
REV:19951031T222710Z
VERSION: 3.0
END:VCARD
--MessageBoundary--
--MessageBoundary--
The following example is for a message returned to the sender by a VPIM gateway at VM1.company.com for a mailbox which does not exist.
次の例は、存在しないメールボックスについて、VM1.company.comのVPIMゲートウェイによって送信者に返されるメッセージです。
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 (Voice 2.0)
Content-Type: multipart/report; report-type=delivery-status;
boundary="RAA14128.773615765/VM1.COMPANY.COM"
--RAA14128.773615765/VM1.COMPANY.COM
Content-type: Audio/32KADPCM
Content-Description: Spoken Delivery Status Notification
Content-Disposition: inline; voice= Voice-Message-Notification
Content-Transfer-Encoding: Base64
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 Content-type：message / delivery-status
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
--RAA14128.773615765/VM1.COMPANY.COM content-type: message/rfc822
--RAA14128.773615765 / VM1.COMPANY.COM content-type：message / rfc822
[original VPIM message goes here]
[元のVPIMメッセージがここに表示されます]
--RAA14128.773615765/VM1.COMPANY.COM--
--RAA14128.773615765 / VM1.COMPANY.COM--
The following example is for a receipt notification sent to the original sender for a message which has been played. This delivered VPIM message was received by a corporate gateway and relayed to a unified mailbox.
次の例は、再生されたメッセージの元の送信者に送信される受信通知です。この配信された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 (Voice 2.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
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 Content-type：message / disposition-notification
Reporting-UA: gregs-laptop.dallas.company.com (Unified FooMail 3.0)
Reporting-UA：gregs-laptop.dallas.company.com（Unified FooMail 3.0）
Original-Recipient: rfc822;22722@vm.company.com
Final-Recipient: rfc822;Greg.Vaudreuil@foomail.company.com
Original-Message-ID: <199509192301.12345@vm2.mycompany.com >
Disposition: manual-action/MDN-sent-automatically; displayed
--RAA14128.773615765/EXCHANGE.COMPANY.COM Content-type: message/rfc822
--RAA14128.773615765 / EXCHANGE.COMPANY.COM Content-type：message / rfc822
[original VPIM message goes here]
[元のVPIMメッセージがここに表示されます]
--RAA14128.773615765/EXCHANGE.COMPANY.COM--
--RAA14128.773615765 / EXCHANGE.COMPANY.COM--
The following common voice processing errors and their corresponding status codes are given as examples. Text after the error codes are 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.0 Persistent connection error because remote system is busy - other
アナログ配信が失敗しました4.4.0リモートシステムがビジー状態であるため、持続的な接続エラー-その他
Analog delivery failed 4.4.1 Persistent protocol error because remote system is - no answer from host ring-no-answer
アナログ配信が失敗しました4.4.1リモートシステムが-ホストからの応答がないため応答がないため、持続的なプロトコルエラー
Remote system did not answer 5.5.5 Permanent protocol error AMIS-Analog handshake ("D" in - wrong version response to "C" at connect time)
リモートシステムが5.5.5の永続的なプロトコルエラーAMIS-Analogハンドシェイクに応答しませんでした（「D」の-接続時の「C」への誤ったバージョンの応答）
Mailbox does not exist 5.1.1 Permanent mailbox error - does not exist
メールボックスが存在しない5.1.1永続的なメールボックスエラー-存在しません
Mailbox full or over quota 4.2.2 Persistent mailbox error - full
メールボックスがいっぱいまたはクォータを超えている4.2.2永続的なメールボックスエラー-いっぱい
Disk full 4.3.1 Persistent system error - full
ディスクがいっぱいです4.3.1永続的なシステムエラー-いっぱい
Command out of sequence 5.5.1 Permanent protocol error - invalid command
コマンドの順序が正しくない5.5.1永続的なプロトコルエラー-無効なコマンド
Frame Error 5.5.2 Permanent protocol error - syntax error
フレームエラー5.5.2永続的なプロトコルエラー-構文エラー
Mailbox does not support FAX 5.6.1 Permanent media error - not supported
メールボックスはFAX 5.6.1の永続的なメディアエラーをサポートしていません-サポートされていません
Mailbox does not support TEXT 5.6.1 Permanent media error - not supported
メールボックスは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永続的なシステムエラーシステムはプライベート対応ではありません-機能対応ではありません
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
メールボックスから削除されたメッセージmanual-action / MDN-sent-automatically;削除されたリスニングなしのユーザーによる
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
To: ietf-mime-directory@imc.org
と： いえｔｆーみめーぢれｃとｒｙ＠いｍｃ。おｒｇ
Subject: Registration of new parameter for text/directory MIME type EMAIL
件名：テキスト/ディレクトリMIMEタイプEMAILの新しいパラメーターの登録
Type name: EMAIL
タイプ名：EMAIL
Type purpose: To specify the electronic mail address for communication with the object the vCard represents (defined in [VCARD]).
タイプの目的：vCardが表すオブジェクト（[VCARD]で定義）との通信用の電子メールアドレスを指定します。
Type encoding: 8bit
タイプエンコーディング：8ビット
Type value: A single text value.
タイプ値：単一のテキスト値。
Type special notes: The type may include the type parameter "TYPE" to specify the format or preference of the electronic mail address. The TYPE parameter values previously defined include: "internet" to indicate an Internet addressing type, "x400" to indicate a X.400 addressing type and "pref" to indicate a preferred-use email address when more than one is specified. The value of "vpim" is defined to indicate that the address specified supports VPIM messages. Other IANA registered address type may also be specified. The default email type is "internet". A non-standard value may also be specified.
タイプ特記事項：タイプには、タイプパラメータ「TYPE」を含めて、電子メールアドレスの形式または設定を指定できます。以前に定義されたTYPEパラメータ値には、インターネットアドレッシングタイプを示す「internet」、X.400アドレッシングタイプを示す「x400」、複数が指定されている場合の優先使用電子メールアドレスを示す「pref」が含まれます。 「vpim」の値は、指定されたアドレスがVPIMメッセージをサポートすることを示すために定義されています。他のIANA登録アドレスタイプも指定できます。デフォルトの電子メールタイプは「インターネット」です。非標準値も指定できます。
Type example:
EMAIL;TYPE=internet,vpim:jqpublic@xyz.dom1.com
To: IANA@IANA.ORG
と： いあな＠いあな。おＲＧ
Subject: Registration of new Content-Disposition parameter
件名：新しいContent-Dispositionパラメーターの登録
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
Voice-Message-プライマリ音声メッセージ、Voice-Message-Notification-音声配信通知または音声処理通知、Originator-Spoken-Name-発信者の音声名、Recipient-Spoken-Name-受信者の音声名発信者が利用でき、受信者が1人だけの場合に表示されます。Spoken-Subject-メッセージの音声の件名。通常は発信者が話します。
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つだけ存在する必要があることに注意してください。添付された転送音声メッセージ内で、特定のタイプ（パラメータ値など）の追加インスタンスが発生する場合があります。
The updated profile in this document is based on the experience of a proof of concept demonstration of VPIM at EMA'96 in April 1996 and a subsequent demonstration of products at EMA'97 in April 1997. This version of the profile is significantly different from the previous described in [VPIM1]. The changes are categorized as general, content, transport and compliance. They are detailed below:
このドキュメントの更新されたプロファイルは、1996年4月にEMA'96でVPIMの概念実証デモを行い、その後1997年4月にEMA'97で製品をデモした経験に基づいています。このバージョンのプロファイルは、以前は[VPIM1]で説明されています。変更は、一般、コンテンツ、トランスポート、コンプライアンスに分類されます。以下に詳細を示します。
1. General
1. 一般的な
- All definitions are now contained in separate documents that are referenced by this profile. The new documents include:
- すべての定義は、このプロファイルによって参照される個別のドキュメントに含まれるようになりました。新しいドキュメントは次のとおりです。
- a refined multipart/voice-message definition
- 洗練されたマルチパート/音声メッセージ定義
- a refined (i.e., added nibble order) audio/32KADPCM definition
- 洗練された（つまり、追加されたニブル順序）オーディオ/ 32KADPCM定義
- the definitions of TIFF-F and image/tiff for fax images
- FIFF画像のTIFF-Fおよびimage / tiffの定義
- the Content-Duration definition
- Content-Duration定義
- Changed the Voice version to 2.0
- Voiceのバージョンを2.0に変更しました
- Added Table of Contents and more examples
- 目次とその他の例を追加
- Various editorial updates to improve readability
- 読みやすさを向上させるためのさまざまな編集上の更新
- Added more security considerations
- セキュリティに関する考慮事項を追加
2. Content
2. コンテンツ
- Modified multipart/voice-message content type by dropping the positional dependence of contents while restricting its contents to voice message specific content types
- マルチパート/ボイスメッセージのコンテンツタイプを変更し、コンテンツの位置依存性を削除しながら、コンテンツをボイスメッセージ固有のコンテンツタイプに制限
- Explicitly indicated other contents that may be present ina multipart/mixed content type
- マルチパート/混合コンテンツタイプに存在する可能性がある他のコンテンツを明示的に示す
- Explicitly defined the forwarding model using message/RFC822
- メッセージ/ RFC822を使用して転送モデルを明示的に定義
- Explained the use of reply-to and from header fields for addressing message replies
- メッセージの返信をアドレス指定するためのreply-toおよびfromヘッダーフィールドの使用について説明しました
- Deprecated the special "loopback" address because of security concerns and its use only for testing
- セキュリティ上の懸念とテストのみでの使用のため、特別な「ループバック」アドレスを廃止
- Defined the non-mail-user reserved address to support the case in which replies to the originator are not possible
- 発信者への返信が不可能である場合をサポートするために、非メールユーザー予約アドレスを定義しました
- Eliminated the text name in the "To" and "CC" header fields. Deprecated ordering of text names in the "From" header.
- 「To」および「CC」ヘッダーフィールドのテキスト名を削除しました。 「From」ヘッダーでのテキスト名の非推奨の順序。
- Added support for facsimile using TIFF-F in an image/tiff; application=faxbw content type
- image / tiffでTIFF-Fを使用したファクシミリのサポートが追加されました。 application = faxbwコンテンツタイプ
- Profiled vCard in the text/directory body part for transport of directory information about the originator
- 発信者に関するディレクトリ情報を転送するためのtext / directory bodyパートのプロファイル済みvCard
- Loosened text restriction
- 緩んだテキスト制限
- Added additional details on delivery and receipt notifications
- 配信および受領通知に関する追加の詳細を追加
- Added support for message disposition notifications, also known as receipt notifications.
- メッセージ処理通知（受信通知とも呼ばれる）のサポートが追加されました。
- Added suggested addressing formats
- 提案されたアドレス形式を追加
- Described handling of private messages
- プライベートメッセージの処理の説明
- Described the handling of non-profiled contents in VPIM messages
- VPIMメッセージのプロファイルされていないコンテンツの処理について説明しました
- Described the use of Content-Disposition to semantically identify audio contents
- 音声コンテンツを意味的に識別するためのContent-Dispositionの使用について説明した
3. Transport
3. 輸送
- Moved binary support to optional
- バイナリサポートをオプションに移動
- Added optional ESMTP keywords for return of content, enhanced status codes, original recipient, and envelope ID
- コンテンツを返すためのオプションのESMTPキーワード、拡張ステータスコード、元の受信者、およびエンベロープIDを追加
- Described use of null MAIL FROM address
- NULL MAIL FROMアドレスの使用の説明
4. Compliance
4. コンプライアンス
- Added an explicit section on conformance specifying conformance to content or transport
- コンテンツまたはトランスポートへの適合を指定する適合に関する明示的なセクションを追加
- Improved conformance table in Appendix A
- 付録Aの改善された適合表
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントとその翻訳はコピーして他のユーザーに提供することができ、コメントまたはその他の方法で説明したり、その実装を支援する二次的著作物は、いかなる種類の制限なしに、全体または一部を準備、コピー、公開、および配布することができますただし、上記の著作権表示とこの段落は、そのようなすべてのコピーと派生物に含まれています。ただし、このドキュメント自体は、著作権に関する通知を削除したり、インターネットソサエティや他のインターネット組織への参照を削除したりするなど、いかなる方法でも変更できません。ただし、インターネット標準を開発する目的で必要な場合は除きます。インターネット標準のプロセスに従うか、または必要に応じて、それを英語以外の言語に翻訳する必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記で付与された制限付きのアクセス許可は永続的であり、インターネットソサエティまたはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。