[要約] RFC 3773は、インターネットボイスメールの高レベル要件を定義しており、インターネットベースのボイスメールシステムの設計と実装に関するガイドラインを提供しています。このRFCの目的は、ボイスメールシステムの機能と相互運用性を向上させるための要件を明確にすることです。
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）The Internet Society（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に準拠したメールクライアントを含むがこれらに限定されません）。Unifiedメッセージング（UM）を介してボイスメールと電子メールを統合する傾向があるため、デスクトップアプリケーションと統一されたメッセージングシステム（インターネットFACSIMILE [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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、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は、インターネットFAX（拡張モード）提案された標準とFAXボディパーツを含む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.
- Voice over 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.
ほとんどの電子メールリーダーはテキスト/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]を受信できる可能性があり、Legacy受信システムが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メッセージを含むメッセージを、別のタイプのメッセージ（MultiPart/Mixedなど）のメッセージへの添付ファイル、および別のタイプの添付ファイルを含む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は、メールメッセージの一般的なユーザープラクティスと相互運用するメカニズムを提供する必要があります。データベース、再送信、転送、メールダイジェストの作成、および非Audio機器を使用したメッセージへの返信に保存する必要があります。
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の目標を達成するのを妨げるものを除き、RFC 2822 [Drumsimf]のすべての要素をサポートする必要があります。
- 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] Vaudreuil、G。およびG. Parsons、「Toll Quality Voice -32 Kbit/s 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.
[コード] Vaudreuil、G。、「拡張メールシステムステータスコード」、RFC 3463、2003年1月。
[DRUMSMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[Drumsmtp] Klensin、J。、「Simple Mail Transfer Protocol」、RFC 2821、2001年4月。
[DRUMSIMF] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[Drumsimf] Resnick、P。、「インターネットメッセージ形式」、RFC 2822、2001年4月。
[EXFAX] Masinter, L. and D. Wing, "Extended Facsimile Using Internet Mail", RFC 2532, March 1999.
[Exfax] Masinter、L。およびD. Wing、「インターネットメールを使用した拡張ファクシミリ」、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 Kbit/s適応微分パルスコード変調（ADPCM）。
[MIME1] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[Mime1] Freed、N。and N. Borenstein、「多目的インターネットメール拡張機能（MIME）パート1：インターネットメッセージボディの形式」、RFC 2045、1996年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[VPIM2] Vaudreuil, G. and G. Parsons, "Voice Profile for Internet Mail, Version 2", RFC 2421, September 1998.
[VPIM2] Vaudreuil、G。およびG. Parsons、「インターネットメールの音声プロファイル、バージョン2」、RFC 2421、1998年9月。
[VPIM1] Vaudreuil, Greg, "Voice Profile for Internet Mail", RFC 1911, February 1996.
[VPIM1] Vaudreuil、Greg、「インターネットメールの音声プロファイル」、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] Silvestro、L。およびR. Miles、「インターネットメールの音声プロファイルの目標、バージョン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 di SilvestroとRod Miles [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
エミリーキャンデルコマバース200 Quannapowitt Parkway Wakefield、MA 01803電話：1-781-213-2324メール：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）The Internet Society（2004）。この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。