Network Working Group E. Candell
Request for Comments: 3773 Comverse
Category: Informational June 2004
High-Level Requirements for Internet Voice Mail
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004).
著作権（C）インターネット協会（2004）。
Abstract
抽象
This document describes the high-level requirements for Internet Voice Mail (IVM) and establishes a baseline of desired functionality against which proposed MIME profiles for Internet Voice Messaging can be judged. IVM is an extension of the Voice Profile for Internet Mail (VPIM) version 2 designed to support interoperability with desktop clients. Other goals for this version of VPIM include expanded interoperability with unified messaging systems, conformance to Internet standards, and backward compatibility with voice messaging systems currently running in a VPIM enabled environment. This document does not include goals that were met fully by VPIM version 2.
この文書は、インターネットボイスメール（IVM）のための高レベルの要件を説明し、判断することができるインターネットボイスメッセージのMIMEプロファイルを提案し、それに対して所望の機能のベースラインを確立します。 IVMは、デスクトップクライアントとの相互運用性をサポートするように設計されたインターネットメール（VPIM）バージョン2用の音声プロファイルを拡張したものです。 VPIMのこのバージョンのための他の目的は、拡張され、ユニファイドメッセージングシステムとの相互運用性、インターネット標準への準拠、および現在VPIM対応環境で実行されているボイスメッセージシステムとの後方互換性があります。このドキュメントでは、VPIMバージョン2で完全に満たされた目標には含まれません。
Until recently, voice mail and call answering services were implemented as stand-alone proprietary systems. Today, standards such as the Voice Profile for Internet Mail (VPIM) enable interoperability between such systems over the Internet. VPIM version 1 [VPIM1] was experimental and was a first attempt at a Voice Profile for Internet Mail, but is now classified as Historical. VPIM Version 2 [VPIM2] is an improvement on VPIM version 1 that was originally intended to provide interoperability between voice messaging systems only. It describes a messaging profile that standardizes the exchange of voice mail over an IP messaging network using SMTP [DRUMSMTP] and MIME [MIME1].
最近まで、ボイスメール、通話応答サービスは、スタンドアロンの専用システムとして実装されました。今日、インターネットメール用の音声プロファイル（VPIM）などの規格は、インターネット上で、このようなシステム間の相互運用性を可能にします。 VPIMバージョン1 [VPIM1]は実験だったとインターネットメール用の音声プロファイルで初めての試みだったが、現在は歴史的に分類されます。 VPIMバージョン2 [VPIM2】本来のみボイスメールシステム間の相互運用性を提供することを意図したVPIMバージョン1の改良です。これは、SMTP [DRUMSMTP]とMIME [MIME1]を使用してIPメッセージングネットワーク上での音声メールのやり取りを標準化し、メッセージングプロファイルを記述する。
Because the number of desktop boxes is growing rapidly and will soon approach the number of desktop telephones, it is essential to consider the requirements of desktop email client applications (including, but not limited to, MIME-compliant email clients). With the trend toward integration of voice mail and email through unified messaging (UM), it is now necessary to define a profile that supports the needs of desktop applications and unified messaging systems (including Internet Facsimile [EXFAX]). This profile is being referred to as Internet Voice Mail (IVM).
デスクトップボックスの数は急速に成長しており、すぐにデスクトップの電話の数に近づきますので、（MIME準拠の電子メールクライアントを含むが、これらに限定されない）デスクトップメールクライアントアプリケーションの要件を考慮することが不可欠です。ユニファイドメッセージング（UM）を介して、ボイスメールと電子メールの統合の傾向と、デスクトップアプリケーションと（インターネットファクシミリ[EXFAX]を含む）、ユニファイドメッセージングシステムのニーズをサポートしているプロファイルを定義することになりまし必要があります。このプロファイルは、インターネットボイスメール（IVM）と呼ばれています。
This document defines the goals for Internet Voice Mail. This standard will support the interchange of voice messages between voice mail systems, unified messaging systems, email servers, and desktop client applications. The desktop client application is of particular and important interest to IVM. This document will also expand the offerings of service providers by facilitating access to voice mail from a web client.
このドキュメントはインターネットボイスメールの目標を定義します。この規格は、ボイスメールシステム、ユニファイドメッセージングシステム、電子メールサーバ、およびデスクトップ・クライアント・アプリケーション間の音声メッセージの交換をサポートします。デスクトップクライアントアプリケーションは、IVMに特に重要な関心事です。また、このドキュメントでは、Webクライアントからのボイスメールへのアクセスを容易にすることにより、サービスプロバイダの提供を拡大していきます。
The following terms have specific meaning in this document:
以下の用語は、本文書に特定の意味を持っています：
"service" An operational service offered by a service provider "application" A use of systems to perform a particular function "terminal" The endpoint of a communication application "goal" An objective of the standardization process
「サービス」は、特定の機能を実行するためにサービスプロバイダ「アプリケーション」によってシステムの使用を提供運用サービス「端末」通信アプリケーションのエンドポイントは「ゴール」標準化プロセスの目的
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 BCP 14, RFC 2119 [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますBCP 14、RFC 2119 [RFC2119]に記載されているように解釈されます。
Enhanced interoperability is the primary goal of IVM. The profile MUST facilitate interoperability between voice mail systems, unified messaging systems, Internet email servers, and desktop client applications. Such interoperability MUST support systems which combine multiple media types in a single message, as well as legacy voice mail and email systems. It MUST allow the ability to accommodate varying capabilities of the voice mail, unified messaging, and email systems. Furthermore, IVM MUST be compatible with Internet Fax (extended mode) proposed standards and VPIM messages that contain fax body parts.
強化された相互運用性は、IVMの主な目的です。プロファイルには、ボイスメールシステム、ユニファイドメッセージングシステム、インターネットの電子メールサーバ、およびデスクトップクライアントアプリケーション間の相互運用性を促進しなければなりません。このような相互運用性は、単一のメッセージ内の複数のメディアタイプを組み合わせたシステムと同様に、従来のボイスメールや電子メールシステムをサポートしなければなりません。これは、ボイスメール、ユニファイドメッセージング、および電子メールシステムの様々な機能に対応するための能力を許容しなければなりません。さらに、IVMは、インターネットファクス（拡張モード）提案された標準とファックス身体の部分が含まれているVPIMメッセージと互換性がなければなりません。
To have "interoperability" means that an IVM compliant sender attempting to send to a recipient will not fail because of incompatibility. IVM MUST support interoperability amongst the systems listed below:
「相互運用性」を有するとは、受信者に送信しようとIVM準拠した送信者がいるため互換性の失敗しないことを意味します。 IVMは、下記のシステム間の相互運用性をサポートしなければなりません：
- Desktop Email client applications - IVM-capable Voice Mail systems - IVM-capable unified messaging systems - Traditional email servers
- デスクトップメールクライアントアプリケーション - IVM対応のボイスメールシステム - IVM対応のユニファイド・メッセージング・システム - 伝統メールサーバ
IVM SHOULD also support interoperability with VPIM version 2 Voice Mail Systems.
IVMはまた、VPIMバージョン2つのボイスメールシステムとの相互運用性をサポートする必要があります。
IVM MUST include new functionality to facilitate access to voice mail messages from desktop applications.
IVMは、デスクトップアプリケーションからのボイスメールメッセージへのアクセスを容易にするための新機能を含まなければなりません。
Overall interoperability requires interoperability for all message elements: body parts deemed essential for message validity MUST be preserved, essential information MUST be provided in a form that is accessible by the users, status codes [CODES] MUST be understood, and operations that are standard for each system SHOULD be supported.
、保存されなければならない体の部分がメッセージの有効性のために必須と考え重要な情報は、ユーザによってアクセス可能なフォーム、ステータスコードで提供されなければならない[コード]理解されなければならない、とのための標準的な操作：全体的な相互運用性は、すべてのメッセージ要素の相互運用性を必要とします各システムがサポートされる必要があります。
Desktop email applications are typically text based. The abilities to listen to, reply to, forward, and generate voice mail messages from a traditional desktop environment are relatively new developments. To accommodate current use and future developments in this area, IVM MUST provide features to support access to voice mail messages from the desktop and other email-reading devices. Also, web access to voicemail SHOULD be supported from the desktop.
デスクトップ電子メールアプリケーションは、一般的にテキストベースです。能力は比較的新しい開発され、従来のデスクトップ環境からボイスメールメッセージを転送、返信、および生成に耳を傾けます。この分野での現在の使用と将来の発展に対応するために、IVMは、デスクトップや他の電子メールの読み取りデバイスからのボイスメールメッセージへのアクセスをサポートするための機能を提供しなければなりません。また、ボイスメールへのWebアクセスは、デスクトップからサポートされる必要があります。
IVM SHOULD NOT require desktop email applications to possess a large amount of processing power, and a base level implementation MUST interoperate, even if it does not offer complex processing. In order to support interoperability, at least one mandatory codec MUST be defined. The mandatory codec(s) SHOULD be widely available on desktops. For interoperability with VPIM version 2 systems, IVM applications MAY also support the VPIM v2 mandatory codec, 32KADPCM [ADPCM and G726-32].
IVMは、処理能力を大量に保有するデスクトップメールアプリケーションを必要とすべきではない、とベースレベルの実装は、それが複雑な処理を提供していない場合でも、相互運用しなければなりません。相互運用性をサポートするために、少なくとも1つの必須コーデックを定義する必要があります。必須コーデック（複数可）のデスクトップ上で広く利用可能であるべきです。 VPIMバージョン2つのシステムとの相互運用性のために、IVMアプリケーションもVPIM v2の必須コーデック、32KADPCM [ADPCMとG726-32]をサポートするかもしれません。
Any codecs included in the IVM specification SHOULD meet the following criteria:
以下の基準を満たす必要がありIVM仕様に含まどれコーデック：
- Availability on desktops: Codecs SHOULD be available on most platforms.
- デスクトップ上の可用性：コーデックはほとんどのプラットフォームで利用可能であるべきです。
- Source code availability: Source code SHOULD be readily accessible.
- ソースコードの可用性：ソースコードは、容易にアクセスできる必要があります。
- Decoding complexity: All codecs MUST be low complexity to decode.
- 復号化の複雑：すべてのコーデックをデコードするために、低複雑でなければなりません。
- Encoding complexity: Some of the codecs MUST be low complexity to encode.
- エンコーディングの複雑さ：コーデックの一部をコード化するために低複雑でなければなりません。
- Bit rate: IVM SHOULD specify a codec with low bit rate for devices (i.e., wireless) that do not have much space/bandwidth.
- ビットレート：IVMは多くのスペース/帯域幅を持っていないデバイスのための低ビットレート（すなわち、ワイヤレス）とのコーデックを指定する必要があります。
- Voice Over IP support: IVM SHOULD specify a codec that supports Voice over IP implementations.
- ボイスオーバーIPのサポート：IVMは、IP実装ボイスオーバーをサポートコーデックを指定する必要があります。
Voice Content MUST always be contained in an audio/basic content-type unless the originator is aware that the recipient can handle other content. To enable future support of other formats, IVM SHOULD provide identification of the codec used without requiring interpretation of an audio format. IVM MAY allow audio encodings and formats that are not identified in the IVM specification to support environments in which the sender is aware of the optimal encoding and format for the recipient.
発信者が受信者が他のコンテンツを扱うことができることを認識している場合を除き、音声コンテンツは、常にオーディオ/基本的なコンテンツタイプに含まれなければなりません。他のフォーマットの将来のサポートを可能にするために、IVMは、オーディオフォーマットの解釈を必要とすることなく、使用されるコーデックの識別を提供すべきです。 IVMは、IVM仕様で識別されていないオーディオエンコーディングや形式は、送信者が受信者に最適なエンコーディングや形式を認識している環境をサポートすることを可能にします。
To address performance and bandwidth issues, IVM MAY support streaming of IVM audio to the desktop. IVM MAY explicitly support formats other than raw audio to facilitate streaming.
パフォーマンスと帯域幅の問題に対処するために、IVMは、デスクトップにIVMオーディオのストリーミングをサポートするかもしれません。 IVMは、明示的にストリーミングを容易にするために、生のオーディオ以外の形式をサポートするかもしれません。
Because most email readers are text/html based and because many devices are not capable of recording audio content, IVM MUST allow inclusion of text body parts in a voice message. IVM SHOULD NOT explicitly prohibit other media types as long as critical content is identified and minimal discard rules are specified.
ほとんどの電子メールの読者があるのでtext / htmlでは、ベースと、多くのデバイスは、オーディオコンテンツを記録することができないので、IVMは、音声メッセージのテキストの体の部分を含めることを許容しなければなりません。 IVMは、明示的に限り、重要なコンテンツが識別され、最小限の廃棄ルールが指定されているように、他のメディアタイプを禁止すべきではありません。
To support devices that have applications dedicated to specific media types or that are not capable of handling specific content, IVM SHOULD define a way to describe the content of the message, indicating how the content can be accessed.
特定のメディアタイプに専用のアプリケーションを持っているか、それが特定のコンテンツを扱うことができないデバイスをサポートするために、IVMは、コンテンツにアクセスできるかを示す、メッセージの内容を記述する方法を定義する必要があります。
Desktop implementation of IVM MUST support attachments of any media type.
IVMのデスクトップの実装では、任意のメディアタイプの添付ファイルをサポートしなければなりません。
Voice messaging systems are generally implemented as special-purpose machines that interface to a telephone switch and provide call answering and voice messaging services. VPIM version 2 was designed to support interoperability between such systems and remains the best messaging profile for this purpose.
ボイスメッセージングシステムは、一般的に通話応答および音声メッセージングサービスを提供する電話交換機へのインターフェイスと特殊用途のマシンとして実装されています。 VPIMバージョン2は、このようなシステム間の相互運用性をサポートするために設計されており、この目的のために最高のメッセージングプロファイル残りました。
To support interoperability between IVM voice messaging systems and other compliant systems, IVM SHOULD have a minimum set of required features that will guarantee interoperability, and also provision for additional functionality that may be supported by more complex systems. IVM MUST define a mechanism for identifying essential content and status codes [CODES] indicating that a message could not be delivered due to capability differences.
IVMの音声メッセージングシステムと他の準拠のシステム間の相互運用性をサポートするために、IVMは、相互運用性、および、より複雑なシステムによってサポートされる追加機能のための提供を保証する必要な機能の最小セットを持っているべきです。 IVMは、メッセージが原因能力の違いに配信することができなかったことを示す[コード]不可欠なコンテンツとステータスコードを識別するためのメカニズムを定義しなければなりません。
NOTE: IVM SHOULD provide some level of interoperability with VPIM version 2 voice messaging systems. In order to support minimal interoperability between IVM and VPIM version 2, IVM systems MAY be able to receive the VPIM version 2 32KADPCM codec [ADPCM and G726- 32], and MUST gracefully handle the case where a legacy receiving system does not support the IVM codecs.
注：IVMは、VPIMバージョン2のボイスメッセージングシステムとの相互運用性のいくつかのレベルを提供する必要があります。 IVMとVPIMバージョン2との間の最小の相互運用性をサポートするために、IVMシステムは、VPIMバージョン2 32KADPCMコーデック[ADPCMとG726- 32]を受信することであってもよく、正常レガシー受信システムは、IVMをサポートしていない場合を処理する必要がありますコーデック。
Unified messaging solutions typically leverage common store, directory, and transport layers to provide greater interoperability and accessibility to a variety of media content. They support creation of and access to voicemail, email, and fax messages from a single user interface.
ユニファイドメッセージングソリューションは、通常、メディアコンテンツの様々な相互運用性とアクセシビリティを提供するために、共通ストア、ディレクトリ、およびトランスポート層を活用します。彼らは、単一のユーザーインターフェイスからボイスメール、電子メール、およびファックスメッセージへの作成とアクセスをサポートしています。
To accommodate the common functionality of unified messaging systems, IVM MUST support the inclusion of body parts containing different media types. It MUST also handle messages that contain VPIM messages as attachments to messages of another type (such as multipart/mixed), and VPIM messages that contain attachments of another type.
ユニファイドメッセージングシステムの共通の機能に対応するために、IVMは、異なるメディアタイプを含む身体の部分を含めることをサポートしなければなりません。それはまた、（例えば、マルチパート/混合のような）他の種類のメッセージに添付ファイルとしてVPIMメッセージ、及び他の種類の添付ファイルを含むVPIMメッセージを含むメッセージを処理しなければなりません。
To provide interoperability with systems that cannot handle a particular content type, IVM MUST provide a mechanism for identifying critical content and MAY define media specific status codes and strings to handle non-delivery of these body parts.
特定のコンテンツタイプを処理できないシステムとの相互運用性を提供するために、IVMは、重要なコンテンツを識別するためのメカニズムを提供する必要があり、これらの身体部分の非配信を処理するためにメディア固有のステータスコードと文字列を定義することができます。
Traditional email servers are those that support only textual media as inline content. IVM MUST interoperate consistently with the current Internet mail environment. If an IVM message arrives in users' mailboxes, IVM MUST provide a mechanism to interoperate with common user practices for mail messages: storing them in databases, retransmission, forwarding, creation of mail digests, and replying to messages using non-audio equipment.
従来の電子メールサーバーは、インラインコンテンツとしてのみテキストメディアをサポートするものです。 IVMは、現在のインターネットのメール環境で一貫相互運用しなければなりません。 IVMメッセージがユーザーのメールボックスに到着した場合、IVMは、メールメッセージの一般的なユーザープラクティスと相互運用するためのメカニズムを提供する必要があります、データベースに格納再送信、転送、メールダイジェストの作成、および非オーディオ機器を使用してメッセージに返信します。
It is the goal of IVM to conform as closely as possible to existing standards while meeting the other goals defined in this document.
この文書で定義された他の目標を満たしながら、既存の標準にできるだけ密接に適合するIVMの目標です。
- Restrictions: The profile SHOULD impose as few restrictions as possible to existing Internet mail standards. In particular, it MUST support all elements of RFC 2822 [DRUMSIMF], except those that prevent the profile from meeting other IVM goals.
- 制限事項：プロファイルは、既存のインターネットメール規格にできるだけ少数の制限を課すべきです。特に、それは他のIVMの目標を達成するからプロファイルを防ぐものを除いて、[DRUMSIMF] RFC 2822のすべての要素をサポートしなければなりません。
- Additions: The profile SHOULD make as few additions as possible to existing internet mail standards. It SHOULD adhere to existing desktop conventions in desktop-related areas such as file extensions. If it is necessary to define new MIME types or sub-types, the IVM work group SHOULD propose terms that are already standard or in common use in the desktop environment.
- 追加：プロファイルは、既存のインターネットメール規格にできるだけ少数の追加を行うべきです。このようなファイル拡張子などのデスクトップ関連の分野における既存のデスクトップ規則に従う必要があります。それが新しいMIMEタイプまたはサブタイプを定義する必要がある場合には、IVMの作業グループはすでに標準またはデスクトップ環境で一般に使用されている用語を提案すべきです。
This profile SHOULD provide backward compatibility with VPIM version 2 to the extent that the functionality required to meet the goals of this profile is not compromised. Where backward compatibility is not possible, IVM SHOULD provide and define a minimal set of rules and status codes for handling non-delivery of IVM messages resulting from interoperability with VPIM version 2 systems and other legacy systems.
このプロファイルは、このプロファイルの目標を達成するために必要な機能が損なわれない範囲で、VPIMバージョン2との下位互換性を提供する必要があります。下位互換性が不可能な場合、IVMを提供し、VPIMバージョン2システムおよび他のレガシー・システムとの相互運用性に起因IVMメッセージの配信不能を処理するためのルールとステータスコードの最小セットを定義する必要があります。
IVM MUST be usable in an environment in which there exist legacy gateways that do not understand MIME. Core features and critical data MUST not be lost when messages pass through AMIS gateways [AMIS-A and AMIS-D]. IVM SHOULD allow interoperability with recipient devices and gateways that have limited buffering capabilities and cannot buffer all header information.
IVMは、MIMEを理解していない従来のゲートウェイが存在する環境で使用可能でなければなりません。メッセージはAMISゲートウェイ[AMIS-AおよびAMIS-D]を通過するとき、コア機能および重要なデータが失われてはいけません。 IVMは、緩衝能力が限られているし、すべてのヘッダ情報をバッファリングすることができない受信者のデバイスやゲートウェイとの相互運用を可能にしなければなりません。
To facilitate security, IVM MUST support authenticated and/or encrypted voice messages. In addition, IVM MUST adhere to the security issues identified in VPIM v2 [VPIM2] and in the other RFCs referenced by this document, especially SMTP [DRUMSMTP], Internet Message Format [DRUMSIMF], and MIME [MIME1].
セキュリティを容易にするために、IVMは、認証および/または暗号化された音声メッセージをサポートしなければなりません。また、IVMはVPIM v2の[VPIM2]で識別されたセキュリティ上の問題に、この文書、特にSMTP [DRUMSMTP]、インターネットメッセージ形式[DRUMSIMF]、およびMIME [MIME1]が参照する他のRFCに準拠する必要があります。
[ADPCM] Vaudreuil, G. and G. Parsons, "Toll Quality Voice - 32 kbit/s ADPCM: MIME Sub-type Registration", RFC 2422, September 1998.
[ADPCM]ヴォードルイユ、G.とG.パーソンズ、 "トール品質の音声 - 32キロビット/秒ADPCM：MIMEサブタイプ登録"、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日。
[CODES] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 3463, January 2003.
[CODES]ヴォードルイユ、G.、 "強化されたメールシステムステータスコード"、RFC 3463、2003年1月。
[DRUMSMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[DRUMSMTP] Klensin、J.、 "簡易メール転送プロトコル"、RFC 2821、2001年4月。
[DRUMSIMF] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[DRUMSIMF]レズニック、P.、 "インターネットメッセージ形式"、RFC 2822、2001年4月。
[EXFAX] Masinter, L. and D. Wing, "Extended Facsimile Using Internet Mail", RFC 2532, March 1999.
[EXFAX] Masinter、L.とD.ウィング、 "インターネットメールを使用して、拡張ファクシミリ"、RFC 2532、1999年3月。
[G726-32] 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-32] CCITT勧告G.726（1990）、デジタル伝送システム、端末機器の一般的側面 - 40、32,24,16はキロビット/適応差分パルス符号変調（ADPCM）がね。
[MIME1] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[MIME1]解放され、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）第一部：インターネットメッセージ本体のフォーマット"、RFC 2045、1996年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[VPIM2] Vaudreuil, G. and G. Parsons, "Voice Profile for Internet Mail, Version 2", RFC 2421, September 1998.
[VPIM2]ヴォードルイユ、G.とG.パーソンズ、 "インターネットメール、バージョン2用の音声プロファイル"、RFC 2421、1998年9月。
[VPIM1] Vaudreuil, Greg, "Voice Profile for Internet Mail", RFC 1911, February 1996.
[VPIM1]ヴォードルイユ、グレッグ、 "インターネットメール用の音声プロファイル"、RFC 1911、1996年2月。
[VPIM3] Silvestro, L. and R. Miles, "Goals for Voice Profile for Internet Mail, Version 3", Work in Progress, March 2000.
[VPIM3]シルヴェストロ、L.およびR.マイルズ、「インターネットメール、バージョン3のための音声プロファイルの目標」、進歩、2000年3月の作品。
This document is the final result of an evolving requirements document that started with VPIM v3 and evolved into an alternative specification for a different (i.e., end-to-end instead of server-to-server) application. The basis for this document was written by Laile Di Silvestro and Rod Miles [VPIM3].
この文書では、VPIMのV3で開始し、異なる（即ち、エンド・ツー・エンドの代わりに、サーバー間の）アプリケーションのための代替的な仕様に進化進化要件文書の最終結果です。このドキュメントのための基礎はLaileディシルヴェストロとロッドマイル[VPIM3]によって書かれました。
The author gratefully acknowledges the authors of [VPIM3], and the input and feedback provided by the members of the EMA and IETF VPIM work groups.
作者は感謝[VPIM3]の著者、およびEMA及びIETF VPIMワークグループのメンバーによって提供される入力とフィードバックを認めます。
Emily Candell Comverse 200 Quannapowitt Parkway Wakefield, MA 01803 Phone: +1-781-213-2324 EMail: emily.candell@comverse.com
エミリーCandellコンバース200 Quannapowittパークウェイウェイクフィールド、MA 01803電話：+ 1-781-213-2324 Eメール：emily.candell@comverse.com
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
著作権（C）インターネット協会（2004）。この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。