[要約] RFC 4239は、インターネット音声メッセージング（IVM）に関する標準化されたプロトコルを提案しています。その目的は、音声メッセージングのための効率的で信頼性の高い通信手段を提供することです。
Network Working Group S. McRae
Request for Comments: 4239 IBM
Category: Standards Track G. Parsons
Nortel Networks
November 2005
Internet Voice Messaging (IVM)
インターネット音声メッセージング（IVM）
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 (2005).
Copyright（c）The Internet Society（2005）。
Abstract
概要
This document describes the carriage of voicemail messages over Internet mail as part of a unified messaging infrastructure.
このドキュメントでは、統一されたメッセージングインフラストラクチャの一部として、インターネットメールを介したボイスメールメッセージのキャリッジについて説明しています。
The Internet Voice Messaging (IVM) concept described in this document is not a successor format to VPIM v2 (Voice Profile for Internet Mail Version 2), but rather an alternative specification for a different application.
このドキュメントで説明されているインターネット音声メッセージング（IVM）の概念は、VPIM V2（インターネットメールバージョン2の音声プロファイル）の後継形式ではなく、別のアプリケーションの代替仕様です。
For some forms of communication, people prefer to communicate using their voices rather than typing. By permitting voicemail to be implemented in an interoperable way on top of Internet Mail, voice messaging and electronic mail no longer need to remain in separate, isolated worlds, and users will be able to choose the most appropriate form of communication. This will also enable new types of devices, without keyboards, to be used to participate in electronic messaging when mobile, in a hostile environment, or in spite of disabilities.
ある種のコミュニケーションの場合、人々はタイピングするのではなく、自分の声を使用してコミュニケーションをとることを好みます。ボイスメールをインターネットメールに加えて相互運用可能な方法で実装できるようにすることにより、音声メッセージングと電子メールが別々の孤立した世界にとどまる必要がなくなり、ユーザーは最も適切な形式のコミュニケーションを選択できます。これにより、キーボードなしの新しいタイプのデバイスが、モバイル時、敵対的な環境、または障害にもかかわらず、電子メッセージングに参加するために使用できます。
There exist unified messaging systems that will transmit voicemail messages over the Internet using SMTP/MIME, but these systems suffer from a lack of interoperability because various aspects of such a message have not hitherto been standardized. In addition, voicemail systems can now conform to the Voice Profile for Internet Messaging (VPIM v2 as defined in RFC 2421 [VPIMV2] and revised in RFC 3801, Draft Standard [VPIMV2R2]) when forwarding messages to remote voicemail systems. VPIM v2 was designed to allow two voicemail systems to exchange messages, not to allow a voicemail system to interoperate with a desktop e-mail client. It is often not reasonable to expect a VPIM v2 message to be usable by an e-mail recipient. The result is messages that cannot be processed by the recipient (e.g., because of the encoding used), or look ugly to the user.
SMTP/MIMEを使用してインターネット上でボイスメールメッセージを送信する統一されたメッセージングシステムが存在しますが、これらのシステムは、このようなメッセージのさまざまな側面がこれまで標準化されていないため、相互運用性の欠如に悩まされています。さらに、ボイスメールシステムは、リモートボイスメールシステムにメッセージを転送する際に、インターネットメッセージングの音声プロファイル（RFC 2421 [VPIMV2]で定義され、RFC 3801、ドラフト標準[VPIMV2R2]）で改訂された音声プロファイルに準拠できるようになりました。VPIM V2は、2つのボイスメールシステムがメッセージを交換できるように設計されており、ボイスメールシステムがデスクトップ電子メールクライアントと相互運用できるようにしませんでした。VPIM V2メッセージが電子メール受信者が使用できると予想することは、多くの場合、合理的ではありません。結果は、受信者が処理できないメッセージ（たとえば、使用されているエンコードのため）、またはユーザーに醜く見えます。
This document therefore proposes a standard mechanism for representing a voicemail message within SMTP/MIME, and a standard encoding for the audio content, which unified messaging systems and mail clients MUST implement to ensure interoperability. By using a standard SMTP/MIME representation and a widely implemented audio encoding, this will also permit most users of e-mail clients not specifically implementing the standard to still access the voicemail messages. In addition, this document describes features an e-mail client SHOULD implement to allow recipients to display voicemail messages in a more friendly, context-sensitive way to the user, and intelligently provide some of the additional functionality typically found in voicemail systems (such as responding with a voice message instead of e-mail). Finally, how a client MAY provide a level of interoperability with VPIM v2 is explained.
したがって、このドキュメントは、SMTP/MIME内のボイスメールメッセージを表すための標準メカニズムと、統一されたメッセージングシステムとメールクライアントが相互運用性を確保するために実装する必要があるオーディオコンテンツの標準エンコードを提案します。標準のSMTP/MIME表現と広く実装されたオーディオエンコーディングを使用することにより、これにより、標準を具体的に実装してボイスメールメッセージにアクセスしない電子メールクライアントのほとんどのユーザーが許可されます。さらに、このドキュメントについては、クライアントがユーザーにもっと友好的でコンテキストに敏感な方法でボイスメールメッセージを表示できるように電子メールクライアントが実装する機能を説明し、ボイスメールシステムに典型的に見られる追加の機能（電子メールの代わりに音声メッセージで応答するなど）をインテリジェントに提供する機能を説明しています。最後に、クライアントがVPIM V2との相互運用性のレベルをどのように提供するかについて説明します。
It is desirable that unified messaging mail clients also be able to fully interoperate with voicemail servers. This is possible today, providing the client implements VPIM v2 [VPIMV2R2], in addition to this specification, and uses it to construct messages to be sent to a voicemail server.
統一されたメッセージングメールクライアントも、ボイスメールサーバーと完全に相互操作できることが望ましいです。これは今日可能であり、クライアントがこの仕様に加えてVPIM V2 [VPIMV2R2]を実装し、それを使用してボイスメールサーバーに送信されるメッセージを作成します。
The definition in this document is based on the IVM Requirements document [GOALS]. It references separate work on critical content [CRITICAL] and message context [HINT]. Addressing and directory issues are discussed in related documents [ADDRESS], [VPIMENUM], [SCHEMA].
このドキュメントの定義は、IVM要件ドキュメント[目標]に基づいています。クリティカルコンテンツ[クリティカル]およびメッセージコンテキスト[ヒント]に関する個別の作業を参照します。アドレス指定とディレクトリの問題は、関連文書[アドレス]、[vpimenum]、[schema]で説明されています。
Further information on VPIM and related activities can be found at http://www.vpim.org or http://www.ema.org/vpim.
VPIMおよび関連するアクティビティの詳細については、http：//www.vpim.orgまたはhttp://www.ema.org/vpimをご覧ください。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [KEYWORDS].
「必須」、「必須」、「必須」、「「しなければ」、「そうしない」、「そうではない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、RFC-2119 [キーワード]に記載されていると解釈されます。
Voice messages may be created explicitly by a user (e.g., recording a voicemail message in their mail client) or implicitly by a unified messaging system (when it records a telephone message).
ボイスメッセージは、ユーザーが明示的に作成することができます（たとえば、メールクライアントにボイスメールメッセージの記録）または統一されたメッセージングシステム（電話メッセージを記録する場合）によって暗黙的に。
All messages MUST conform with the Internet Mail format, as updated by the DRUMS working group [DRUMSIMF], and the MIME format [MIME1].
すべてのメッセージは、ドラムワーキンググループ[DRUMSIMF]とMIME形式[MIME1]によって更新されるように、インターネットメール形式に準拠する必要があります。
When creating a voice message from a client supporting IVM, the message header MUST indicate a message context of "voice-message" (see [HINT]). However, to support interoperability with clients not explicitly supporting IVM, a recipient MUST NOT require its presence in order to correctly process voice messages.
IVMをサポートするクライアントから音声メッセージを作成する場合、メッセージヘッダーは「音声メッセージ」のメッセージコンテキストを示す必要があります（[ヒント]を参照）。ただし、IVMを明示的にサポートしていないクライアントとの相互運用性をサポートするには、受信者は音声メッセージを正しく処理するためにその存在を必要としてはなりません。
The receiving agent MUST be able to support multipart messages [MIME5]. If the receiving user agent identifies the message as a voice message (from the message context), it SHOULD present it to the user as a voice message rather than as an electronic mail message with a voice attachment (see [BEHAVIOUR]).
受信エージェントは、マルチパートメッセージ[MIME5]をサポートできる必要があります。受信ユーザーエージェントがメッセージを音声メッセージとして（メッセージコンテキストから）識別する場合、音声添付ファイルを備えた電子メールメッセージとしてではなく、ユーザーに音声メッセージとして表示する必要があります（[行動]を参照）。
Any content type is permitted in a message, but the top level content type on a new, forwarded or reply voice message SHOULD be multipart/mixed. If the recipient is known to be VPIM v2 compliant, then multipart/voice-message MAY be used instead (in which case, all the provisions of [VPIMV2R2] MUST be implemented in constructing the message).
任意のコンテンツタイプはメッセージで許可されていますが、新しい、転送された、または返信音声メッセージのトップレベルのコンテンツタイプはMultiPart/Mixedである必要があります。受信者がVPIM V2に準拠していることが知られている場合、代わりにマルチパート/音声メッセージを使用することができます（この場合、[VPIMV2R2]のすべての規定をメッセージの作成に実装する必要があります）。
If the message was created as a voice message, and so is not useful if the audio content is omitted, then the appropriate audio body part MUST be indicated as critical content, via a Criticality parameter of CRITICAL on the Content-Disposition (see [CRITICAL]). Additional important body parts (such as the original audio message if a voicemail is being forwarded) MAY also be indicated via a Criticality of CRITICAL. Contents that are not essential to communicating the meaning of the message (e.g., an associated vCard for the originator) MAY be indicated via a Criticality of IGNORE.
メッセージが音声メッセージとして作成されている場合、オーディオコンテンツが省略されている場合に有用ではない場合、コンテンツ拡張の重要な重要性パラメーターを介して、適切なオーディオ本体の部分をクリティカルコンテンツとして示す必要があります（[批判]を参照）。追加の重要なボディパーツ（ボイスメールが転送されている場合の元のオーディオメッセージなど）も重要な重要性を介して示される場合があります。メッセージの意味を伝えるために不可欠ではない内容（例えば、オリジネーターに関連するVCARD）は、無視の重要性を介して示される場合があります。
When forwarding IVM messages, clients MUST preserve the content type of all audio body parts in order to ensure that the new recipient is able to play the forwarded messages.
IVMメッセージを転送するとき、クライアントは、新しい受信者が転送されたメッセージを再生できるようにするために、すべてのオーディオボディパーツのコンテンツタイプを保存する必要があります。
The top level content type, on origination of a delivery notification message, MUST be a multipart/report. This will allow automatic processing of the delivery notification, for example, so that text-to-speech processing can render a non-delivery notification in the appropriate language for the recipient.
配信通知メッセージの起源に関するトップレベルのコンテンツタイプは、マルチパート/レポートでなければなりません。これにより、たとえば、配信通知の自動処理が可能になり、テキストからスピーチへの処理により、受信者に適切な言語での配信通知が表示されます。
The message MUST be transmitted in accordance with the Simple Mail Transport Protocol, as updated by the DRUMS working group [DRUMSMTP].
メッセージは、ドラムワーキンググループ[DRUMSMTP]によって更新されるように、単純なメールトランスポートプロトコルに従って送信する必要があります。
Delivery Status Notifications MAY be requested [DSN] if delivery of the message is important to the originator and a mechanism exists to return status indications to them (which may not be possible for voicemail originators).
配信ステータス通知が要求される場合があります[DSN]メッセージの配信が発信者にとって重要であり、ステータス表示を返すメカニズムが存在する場合（ボイスメールオリジネーターには不可能かもしれません）。
Any valid Internet Mail address may be used for a voice message.
有効なインターネットメールアドレスは、音声メッセージに使用できます。
It is desirable to be able to use an onramp/offramp for delivery of a voicemail message to a user, which will result in specific addressing requirements, based on service selectors defined in [SELECTOR]. Further discussion of addressing requirements for voice messages can be found in the VPIM Addressing document [ADDRESS].
[セレクター]で定義されたサービスセレクターに基づいて、ユーザーにボイスメールメッセージを配信するためにOnramp/Offrampを使用するためにOnramp/Offrampを使用できることが望ましいです。音声メッセージのアドレス指定要件のさらなる議論は、VPIMアドレスドキュメント[アドレス]に記載されています。
It is desirable to permit the use of a directory service to map between the E.164 phone number of the recipient and an SMTP mailbox address. A discussion on how this may be achieved using the ENUM infrastructure is in [VPIMENUM]. A definition of the VPIM LDAP schema that a system would use is found in [SCHEMA].
Directoryサービスの使用を許可して、受信者のE.164電話番号とSMTPメールボックスアドレスの間でマッピングすることが望ましいです。これが列挙インフラストラクチャを使用してどのように達成されるかについての議論は[vpimenum]にあります。システムが使用するVPIM LDAPスキーマの定義は、[スキーマ]に含まれています。
If a message is created and stored as a result of call answering, the caller's name and number MAY be stored in the message headers in its original format per [CLID].
通話の回答の結果としてメッセージが作成および保存された場合、発信者の名前と番号は、[Clid]ごとに元の形式でメッセージヘッダーに保存される場合があります。
Delivery Status Notifications MUST be supported. All non-delivery of messages MUST result in an NDN, if requested [DSN, DSN2, DSN3, DSN4]. If the receiving system supports content criticality and is unable to process all of the critical media types within a voice message (indicated by the content criticality), then it MUST non-deliver the entire message per [CRITICAL].
配信ステータス通知をサポートする必要があります。メッセージのすべての非配信は、[DSN、DSN2、DSN3、DSN4]を要求した場合、NDNをもたらす必要があります。受信システムがコンテンツのクリティカリ性をサポートし、音声メッセージ内のすべての重要なメディアタイプ（コンテンツクリティカルで示される）を処理できない場合、[クリティカル]ごとにメッセージ全体を非配信する必要があります。
Message Disposition Notifications SHOULD be supported (but according to MDN rules, the user MUST be given the option of deciding whether MDNs are returned) per [MDN].
メッセージ処分通知はサポートする必要があります（ただし、MDNルールに従って、ユーザーには[MDN]ごとにMDNが返されるかどうかを決定するオプションが与えられなければなりません）。
If the recipient is unable to display all of the indicated critical content components indicated, then it SHOULD give the user the option of returning an appropriate MDN (see [CRITICAL]).
受信者が示されている指定されたすべての重要なコンテンツコンポーネントを表示できない場合、ユーザーに適切なMDNを返すオプションを提供する必要があります（[クリティカル]を参照）。
Voice messages may be contained at any location within a message and MUST always be contained in an audio/basic content-type, unless the originator is aware that the recipient can handle other content. Specifically, Audio/32kadpcm MAY be used when the recipient is known to support VPIM v2 [VPIMV2R2].
音声メッセージは、メッセージ内の任意の場所に含まれる場合があり、受信者が他のコンテンツを処理できることを発信者が認識しない限り、常にオーディオ/基本コンテンツタイプに含める必要があります。具体的には、受信者がVPIM V2 [VPIMV2R2]をサポートすることが知られている場合、Audio/32KADPCMを使用できます。
The VOICE parameter on Content-Disposition from VPIM v2 [VPIMV2R2] SHOULD be used to identify any spoken names or spoken subjects (as distinct from voice message contents). As well, the Content-Duration header [DUR] SHOULD be used to indicate the audio length.
VPIM V2 [VPIMV2R2]からのコンテンツ拡散に関する音声パラメーターを使用して、音声メッセージの内容とは異なる）話し言葉を特定するために使用する必要があります。同様に、コンテンツ期間ヘッダー[DUR]を使用して、オーディオの長さを示す必要があります。
The originator's spoken name MAY be included with messages as separate audio contents, if known, and SHOULD be indicated by the Content-Disposition VOICE parameter as defined in VPIM v2 [VPIMV2R2]. If there is a single recipient for the message, the spoken name MAY also be included (per VPIM v2). A spoken subject MAY also be provided (per VPIM v2).
オリジネーターの音声名は、既知の場合、個別のオーディオコンテンツとしてメッセージに含まれている場合があり、VPIM V2 [VPIMV2R2]で定義されているコンテンツディスポジション音声パラメーターで示される必要があります。メッセージに1人の受信者がいる場合、音声名も含めることができます（VPIM V2ごと）。話し言葉も提供される場合があります（VPIM V2ごと）。
A sending implementation MAY determine the recipient capabilities before sending a message and choose a codec accordingly (e.g., using some form of content negotiation). In the absence of such recipient knowledge, sending implementations MUST use raw G.711 mu-law, which is indicated with a MIME content type of "audio/basic" (and SHOULD use a filename parameter that ends ".au") [G711], [MIME2]. A sending implementation MAY support interoperability with VPIM v2 [VPIMV2R2], in which case, it MUST be able to record G.726 (indicated as audio/32kadpcm) [G726], [ADPCM].
送信実装は、メッセージを送信する前に受信者機能を決定し、それに応じてコーデックを選択する場合があります（たとえば、何らかの形のコンテンツネゴシエーションを使用して）。このような受信者の知識がない場合、実装の送信は、raw g.711 mu-lawを使用する必要があります。これは、「audio/basic」のmimeコンテンツタイプで示されています（そして、「.au」）[g711]、[mime2]を終了するファイル名パラメーターを使用する必要があります。送信実装は、VPIM V2 [VPIMV2R2]との相互運用性をサポートする場合があります。この場合、G.726（Audio/32KADPCMとして示されている）[G726]、[ADPCM]を記録できる必要があります。
Recipients MUST be able to play a raw G.711 mu-law message, and MAY be able to play G.726 (indicated as audio/32kadpcm) to provide interoperability with VPIM v2. A receiving implementation MAY also be able to play messages encoded with other codecs (either natively or via transcoding).
受信者は、生のG.711 MU-LAWメッセージを再生できる必要があり、VPIM V2との相互運用性を提供するためにG.726（Audio/32KADPCMとして示されている）を再生できる場合があります。受信実装は、他のコーデックとエンコードされたメッセージを再生することもできます（ネイティブまたはトランスコーディングによる）。
These requirements may be summarized as follows:
これらの要件は、次のように要約できます。
Codec No VPIM v2 Support With VPIM v2 Support
Record Playback Record Playback
------------- ------ -------- ------ --------
G.711 mu-law MUST MUST MUST MUST
G.726 * MAY MUST MUST
Other * MAY * MAY
* = MUST NOT, but MAY only if recipient capabilities known
* =そうではないが、受信者機能がわかっている場合にのみかもしれない
Fax contents SHOULD be carried according to RFC 2532 [IFAX].
ファックスの内容は、RFC 2532 [IFAX]に従って運ばれる必要があります。
Interoperability between VPIM v2 systems and IVM systems can take a number of different forms. While a thorough investigation of how full interoperability might be provided between IVM and VPIM v2 systems is beyond the scope of this document; three key alternatives are discussed below.
VPIM V2システムとIVMシステム間の相互運用性は、さまざまな形をとることができます。IVMとVPIM V2システムの間で完全な相互運用性がどのように提供されるかについての徹底的な調査は、このドキュメントの範囲を超えています。3つの重要な選択肢については、以下で説明します。
If an IVM-conformant client is able to process a content type of multipart/voice-message (by treating it as multipart/mixed) and play a G.726 encoded audio message within it (indicated by a content type of audio/32kadpcm), then a VPIM v2 message that gets routed to that desktop will be at least usable by the recipient.
IVMコンフォータントクライアントがコンテンツタイプのマルチパート/音声メッセージを処理し（マルチパート/混合として扱うことにより）、G.726エンコードされたオーディオメッセージを再生できる場合（コンテンツタイプのオーディオ/32KADPCMで示されています）、DeskTOPにルーティングされるVPIM V2メッセージは、少なくともレシピエントに使用できます。
This delivers a level of partial interoperability that would ease the life of end users. However, care should be taken to ensure that any attempt to reply to such a message does not result in an invalid VPIM v2 message being sent to a VPIM v2 system. Note that replying to an e-mail user who has forwarded a VPIM v2 message to you is, however, acceptable.
これにより、エンドユーザーの寿命を緩和するレベルの部分的な相互運用性が提供されます。ただし、そのようなメッセージに返信しようとしても、VPIM V2システムに送信される無効なVPIM V2メッセージが得られないようにするために注意する必要があります。ただし、VPIM V2メッセージをあなたに転送した電子メールユーザーに返信することは許容されることに注意してください。
A conformant IVM implementation MUST NOT send a non-VPIM v2 message to something it knows to be a VPIM v2 system, unless it also knows that the destination system can handle such a message (even though VPIM v2 systems are encouraged to handle non-VPIM v2 messages in a graceful manner). In general, it must be assumed that if a system sends you a conformant VPIM v2 message, then it is a VPIM v2 system, and so you may only reply with a VPIM v2 compliant message (unless you know by some other means that the system supports IVM).
適合IVM実装は、宛先システムがそのようなメッセージを処理できることもわかっていない限り、VPIM V2システムであることが知っているものに非VPIM V2メッセージを送信してはなりません（VPIM V2システムは、非VPIM V2メッセージを優雅な方法で処理することが奨励されています）。一般に、システムがコンフォーマントVPIM V2メッセージを送信する場合、それはVPIM V2システムであるため、VPIM V2準拠のメッセージでのみ返信できると想定する必要があります（システムがIVMをサポートすることを他の手段で知らない限り）。
In addition, it should be noted that an IVM client may not fully conform to VPIM v2, even if it supports playing a G.726 message (e.g., it may not respect the handling of the Sensitivity field required by VPIM v2). This is one reason why VPIM v2 systems may choose not to route messages to any system they do not know to be VPIM v2 compliant.
さらに、G.726メッセージの再生をサポートしていても、IVMクライアントはVPIM V2に完全に準拠していない可能性があることに注意する必要があります（たとえば、VPIM V2が必要とする感度フィールドの取り扱いを尊重しない場合があります）。これが、VPIM V2システムがVPIM V2に準拠しているとわからないシステムにメッセージをルーティングしないことを選択する理由の1つです。
A VPIM v2 system could be extended to also be able to support IVM compliant messages, and an IVM conformant client could be extended to implement VPIM v2 in full when corresponding with a VPIM v2 compliant system. This is simply a matter of implementing both specifications and selecting the appropriate one, depending on the received message content or the recipient's capabilities. This delivers full interoperability for the relevant systems, providing the capabilities of the target users can be determined.
VPIM V2システムを拡張してIVM準拠のメッセージをサポートすることもでき、VPIM V2準拠システムに対応する場合、IVM適合クライアントをVPIM V2を完全に実装するために拡張できます。これは、受信したメッセージコンテンツまたは受信者の機能に応じて、仕様の両方を実装し、適切な仕様を選択する問題です。これにより、関連するシステムに完全な相互運用性が提供され、ターゲットユーザーの機能を決定できます。
Note that the mechanism for determining if a given recipient is using a VPIM v2 system or client is outside of the scope of this specification. Various mechanisms for capabilities discovery exist that could be applied to this problem, but no standard solution has yet been defined.
特定の受信者がVPIM V2システムまたはクライアントを使用しているかどうかを判断するためのメカニズムは、この仕様の範囲外であることに注意してください。この問題に適用できる能力発見のためのさまざまなメカニズムが存在しますが、標準的なソリューションはまだ定義されていません。
It would be possible to build a gateway linking a set of VPIM v2 users with a set of IVM users. This gateway would implement the semantics of the two worlds, and translate between them according to defined policies.
VPIM V2ユーザーのセットをIVMユーザーのセットとリンクするゲートウェイを構築することが可能です。このゲートウェイは、2つの世界のセマンティクスを実装し、定義されたポリシーに従ってそれらの間を翻訳します。
For example, VPIM v2 messages with a Sensitivity of Private might be rejected instead of forwarded to an IVM recipient, because it might not implement the semantics of a Private message, while an IVM message containing content not supported in VPIM v2 (e.g., a PNG image), with a Criticality of CRITICAL, would be rejected in the gateway.
たとえば、プライベートの感度を持つVPIM V2メッセージは、IVMレシピエントに転送する代わりに拒否される可能性があります。これは、プライベートメッセージのセマンティクスを実装できないため、VPIM V2でサポートされていないコンテンツを含むIVMメッセージ（PNGイメージなど）で、重要性の重要性がgatewayで拒否される可能性があります。
Such a gateway MUST fully implement this specification and the VPIM v2 specification [VPIMV2R2], unless it knows somehow that the specific originators/recipients support capabilities beyond those required by these standards.
このようなゲートウェイは、特定のオリジネーター/受信者がこれらの標準で必要なものを超えて機能する機能をサポートすることを何らかの形で知っていない限り、この仕様とVPIM V2仕様[VPIMV2R2]を完全に実装する必要があります。
This document presents an optional gateway between IVM and VPIM systems. Gateways are inherently lossy systems and not all information can be accurately translated. This applies to both the transcoding of the voice and the translation of features. Two examples of feature translation are given in 9.3, but the risk remains that different gateways will handle the translation differently since it is undefined in this document. This may lead to unexpected behavior through gateways.
このドキュメントでは、IVMシステムとVPIMシステムの間のオプションのゲートウェイを提示します。ゲートウェイは本質的に損失したシステムであり、すべての情報を正確に翻訳できるわけではありません。これは、音声のトランスコーディングと機能の翻訳の両方に当てはまります。機能翻訳の2つの例が9.3に記載されていますが、このドキュメントで定義されていないため、異なるゲートウェイが翻訳を異なる方法で処理するリスクは残ります。これは、ゲートウェイを介して予期しない動作につながる可能性があります。
In addition, gateways present an additional point of attack for those interested in compromising a messaging system. If a gateway is compromised, "monkey in the middle" attacks, conducted from the compromised gateway, may be difficult to detect or appear to be authorized transformations.
さらに、Gatewaysは、メッセージングシステムの侵害に関心のある人々に追加の攻撃ポイントを提示します。ゲートウェイが侵害された場合、侵害されたゲートウェイから行われた「中央の猿」攻撃は、検出が困難であるか、承認された変換であるように見えるかもしれません。
Aside from the gateway issue, it is anticipated that there are no new additional security issues beyond those identified in VPIM v2 [VPIMV2R2] and in the other RFCs referenced by this document -- especially SMTP [DRUMSMTP], Internet Message Format [DRUMSIMF], MIME [MIME2], Critical Content [CRITICAL], and Message Context [HINT].
ゲートウェイの問題は別として、VPIM V2 [VPIMV2R2]で特定されたもの以外の新しい追加のセキュリティ問題はないことが予想されます。また、このドキュメントで参照されている他のRFC、特にSMTP [DRUMSMTP]、インターネットメッセージ形式[DRUMSIMF]、MIME [MIME2]、MIME [MIME2]、批判的なコンテンツ[クリティカル]、[Hint]。
[ADDRESS] Parsons, G., "Voice Profile for Internet Mail (VPIM) Addressing", RFC 3804, June 2004.
[アドレス]パーソンズ、G。、「インターネットメールの音声プロファイル（VPIM）アドレス指定」、RFC 3804、2004年6月。
[ADPCM] Vaudreuil, G. and G. Parsons, "Toll Quality Voice - 32 kbit/s Adaptive Differential Pulse Code Modulation (ADPCM) MIME Sub-type Registration", RFC 3802, June 2004.
[ADPCM] Vaudreuil、G。およびG. Parsons、「Toll Quality Voice -32 kbit/s適応微分パルスコード変調（ADPCM）MIMEサブタイプ登録」、2004年6月、RFC 3802。
[BEHAVIOUR] Parsons, G. and J. Maruszak, "Voice Messaging Client Behaviour", RFC 4024, July 2005.
[行動] Parsons、G。およびJ. Maruszak、「音声メッセージングクライアント行動」、RFC 4024、2005年7月。
[CLID] Parsons, G. and J. Maruszak, "Calling Line Identification for Voice Mail Messages", RFC 3939, December 2004.
[Clid] Parsons、G。and J. Maruszak、「ボイスメールメッセージの呼び出しライン識別」、RFC 3939、2004年12月。
[CRITICAL] Burger, E., "Critical Content Multi-purpose Internet Mail Extensions (MIME) Parameter", RFC 3459, January 2003.
[Critical] Burger、E。、「クリティカルコンテンツ多目的インターネットメールエクステンション（MIME）パラメーター」、RFC 3459、2003年1月。
[DSN] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", RFC 3461, January 2003.
[DSN] Moore、K。、「配送ステータス通知（DSNS）のSimple Mail Transfer Protocol（SMTP）サービス拡張」、RFC 3461、2003年1月。
[DSN2] Vaudreuil, G., "The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages", RFC 3462, January 2003.
[DSN2] Vaudreuil、G。、「メールシステム管理メッセージのレポートのためのマルチパート/レポートコンテンツタイプ」、RFC 3462、2003年1月。
[DSN3] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 3463, January 2003.
[DSN3] Vaudreuil、G。、「Enhanced Mail System Status Codes」、RFC 3463、2003年1月。
[DSN4] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, January 2003.
[DSN4] Moore、K。およびG. Vaudreuil、「配信ステータス通知のための拡張可能なメッセージ形式」、RFC 3464、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月。
[DUR] Vaudreuil, G. and G. Parsons, "Content Duration MIME Header Definition", RFC 3803, June 2004.
[DUR] Vaudreuil、G。およびG. Parsons、「コンテンツ期間MIMEヘッダー定義」、RFC 3803、2004年6月。
[HINT] Burger, E., Candell, E., Eliot, C., and G. Klyne, "Message Context for Internet Mail", RFC 3458, January 2003.
[Hint] Burger、E.、Candell、E.、Eliot、C。、およびG. Klyne、「インターネットメールのメッセージコンテキスト」、RFC 3458、2003年1月。
[IFAX] Masinter, L. and D. Wing, " Extended Facsimile Using Internet Mail", RFC 2532, March 1999.
[IFAX] Masinter、L。およびD. Wing、「インターネットメールを使用した拡張ファクシミリ」、RFC 2532、1999年3月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[MDN] Hansen, T. and G. Vaudreuil, "Message Disposition Notification", RFC 3798, May 2004.
[MDN] Hansen、T。およびG. Vaudreuil、「メッセージ処分通知」、RFC 3798、2004年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、「多目的インターネットメール拡張機能（MIME）パート1：インターネットメッセージボディの形式」、RFC 2045、1996年11月。
[MIME2] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[Mime2] Freed、N。およびN. Borenstein、「多目的インターネットメールエクステンション（MIME）パート2：メディアタイプ」、RFC 2046、1996年11月。
[MIME5] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 2049, November 1996.
[Mime5] Freed、N。and N. Borenstein、「多目的インターネットメール拡張機能（MIME）パート5：適合基準と例」、RFC 2049、1996年11月。
[SELECTOR] Allocchio, C., "Minimal GSTN address format in Internet Mail", RFC 3191, October 2001.
[Selector] Allocchio、C。、「インターネットメールの最小GSTNアドレス形式」、RFC 3191、2001年10月。
[SCHEMA] Vaudreuil, G., "Voice Messaging Directory Service", RFC 4237, October 2005.
[Schema] Vaudreuil、G。、「Voice Messaging Directory Service」、RFC 4237、2005年10月。
[VPIMENUM] Vaudreuil, G., "Voice Message Routing Service", RFC 4238, October 2005.
[vpimenum] Vaudreuil、G。、「音声メッセージルーティングサービス」、RFC 4238、2005年10月。
[VPIMV2] Vaudreuil, G. and G. Parsons, "Voice Profile for Internet Mail - version 2", RFC 2421, September 1998.
[VPIMV2] Vaudreuil、G。およびG. Parsons、「インターネットメールの音声プロファイル - バージョン2」、RFC 2421、1998年9月。
[VPIMV2R2] Vaudreuil, G. and G. Parsons, "Voice Profile for Internet Mail - version 2 (VPIMv2)", RFC 3801, June 2004.
[VPIMV2R2] Vaudreuil、G。およびG. Parsons、「インターネットメールの音声プロファイル -バージョン2（VPIMV2）」、RFC 3801、2004年6月。
[GOALS] Candell, E., "High-Level Requirements for Internet Voice Mail", RFC 3773, June 2004.
[目標] Candell、E。、「インターネットボイスメールの高レベルの要件」、RFC 3773、2004年6月。
[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）。
[G711] ITU-T Recommendation G.711 (1993), General Aspects of Digital Transmission Systems, Terminal Equipment - Pulse Code Modulation (PCM) of Voice Frequencies.
[G711] ITU -Tの推奨G.711（1993）、デジタル伝送システムの一般的な側面、ターミナル機器 - 音声周波数のパルスコード変調（PCM）。
Authors' Addresses
著者のアドレス
Stuart J. McRae IBM Lotus Park, The Causeway< Staines, TW18 3AG United Kingdom
Stuart J. McRae IBM Lotus Park、The Causeway <Staines、Tw18 3ag英国
Phone: +44 1784 445 112
Fax: +44 1784 499 112
EMail: stuart.mcrae@uk.ibm.com
Glenn W. Parsons Nortel Networks 3500 Carling Avenue Ottawa, ON K2H 8E9 Canada
グレン・W・パーソンズ・ノーテル・ネットワーク3500カーリング・アベニュー・オタワ、K2H 8E9カナダ
Phone: +1-613-763-7582
Fax: +1-613-967-5060
EMail: gparsons@nortel.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（2005）。
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.
この文書は、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://ww.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エディター機能の資金は現在、インターネット協会によって提供されています。