RFC4239 日本語訳

Network Working Group                                           S. McRae
Request for Comments: 4239                                           IBM
Category: Standards Track                                     G. Parsons
                                                         Nortel Networks
                                                           November 2005

コメントを求めるワーキンググループS.マクレー要求をネットワークでつないでください: 4239年のIBMカテゴリ: 規格は2005年11月にG.教区牧師ノーテルネットワークを追跡します。

                     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.

このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (2005).

Copyright(C)インターネット協会(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.

本書では説明されたインターネットVoice Messaging(IVM)概念はVPIM v2(インターネットメールバージョン2のための声のProfile)への後継者形式ではなく、むしろ異なったアプリケーションのための代替の仕様です。

1.  Introduction

1. 序論

   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

SMTP/MIMEを使用することでボイスメールメッセージをインターネットの上に送るユニファイド・メッセージングシステムが存在していますが、そのようなメッセージの種々相がこれまで標準化されていないので、これらのシステムは相互運用性の不足が欠点です。 さらに、ボイスメールシステムは現在、インターネットMessagingのためのVoice Profileに一致できます。

McRae & Parsons             Standards Track                     [Page 1]

RFC 4239                Internet Voice Messaging           November 2005

2005年11月に通信するマクレーと教区牧師標準化過程[1ページ]RFC4239インターネット声

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

リモートボイスメールシステムVPIM v2にメッセージを転送するとき、(RFC2421[VPIMV2]で定義されて、RFC3801、Draft Standard[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表現と広く実装しているオーディオを使用することによって、コード化しています、また、これは明確に規格を実装しないメール・クライアントのほとんどのユーザがまだボイスメールメッセージにアクセスしていることを許可するでしょう。 さらに、このドキュメントはメール・クライアントSHOULDが受取人がユーザへの、より好意的で、文脈依存している方法でボイスメールメッセージを表示して、知的にボイスメールシステム(音声メールがメールの代わりにある状態で応じなどなどの)で通常見つけられた追加機能性のいくつかを提供するのを許容するために実装する特徴について説明します。 最終的に、クライアントがどう相互運用性のレベルに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 Requirementsドキュメント[GOALS]に基づいています。 それは重要な内容[CRITICAL]とメッセージの文脈[ヒント]への別途工事に参照をつけます。 関連するドキュメント[ADDRESS]、[VPIMENUM][SCHEMA]でアドレシングとディレクトリ問題について議論します。

   Further information on VPIM and related activities can be found at
   http://www.vpim.org or http://www.ema.org/vpim.

http://www.vpim.org か http://www.ema.org/vpim でVPIMに関する詳細と関連活動を見つけることができます。

2.  Conventions Used in This Document

2. 本書では使用されるコンベンション

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC-2119 [KEYWORDS].

キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC-2119[キーワード]で説明されるように本書では解釈されることであるべきですか?

McRae & Parsons             Standards Track                     [Page 2]

RFC 4239                Internet Voice Messaging           November 2005

2005年11月に通信するマクレーと教区牧師標準化過程[2ページ]RFC4239インターネット声

3.  Message Format

3. メッセージ・フォーマット

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

すべてのメッセージがインターネットメール形式に従わなければなりません、DRUMSワーキンググループ[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]であるとサポートすることができなければなりません。 受信ユーザエージェントは、メッセージが音声メール(メッセージの文脈からの)であると認識します、それ。SHOULDは電子メールメッセージとしてというよりむしろ音声メールとして声の付属をもってユーザにそれを提示します([BEHAVIOUR]を見てください)。

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

どんなcontent typeもメッセージで受入れられますが、複合か混ぜられて、先端は新しい進められるか回答の声のメッセージSHOULDにcontent typeを平らにします。 受取人が次に、VPIM v2対応することの、そして、複合の、または、メッセージを声に出している5月であることが知られているなら、代わりに使用されてください(その場合、メッセージを構成する際に[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.

オーディオ内容が省略されるならメッセージが音声メールとして作成されたので役に立たないなら、重要な内容として適切なオーディオ身体の部分を示さなければなりません、Content-気質のCRITICALのCriticalityパラメタで([CRITICAL]を見てください)。 また、追加重要な身体の部分(ボイスメールであるならオリジナルのオーディオメッセージを転送しているようなもの)はCRITICALのCriticalityを通して示されるかもしれません。 メッセージ(例えば、創始者のための関連vCard)の意味を伝えるのに不可欠でない内容はIGNOREのCriticalityを通して示されるかもしれません。

   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に転送するとき、クライアントは、新しい受取人が転送されたメッセージをプレーできるのを確実にするためにすべてのオーディオ身体の部分のcontent typeを保存しなければなりません。

   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.

配送通知メッセージの創作のときに、最高平らなcontent typeは複合/レポートであるに違いありません。 例えば、これは、スピーチへのテキスト処理が受取人のために適切な言語で非配送通知を表すことができるように、配送通知の自動処理を許すでしょう。

McRae & Parsons             Standards Track                     [Page 3]

RFC 4239                Internet Voice Messaging           November 2005

2005年11月に通信するマクレーと教区牧師標準化過程[3ページ]RFC4239インターネット声

4.  Transport

4. 輸送

   The message MUST be transmitted in accordance with the Simple Mail
   Transport Protocol, as updated by the DRUMS working group [DRUMSMTP].

SimpleメールTransportプロトコルに応じて、メッセージを送らなければなりません、DRUMSワーキンググループ[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).

創始者にとって、メッセージの配送が重要であり、メカニズムがそれら(ボイスメール創始者には、可能でないかもしれない)に状態指摘を返すために存在しているなら、配送Status Notificationsは要求されるかもしれません[DSN]。

5.  Addressing

5. アドレシング

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

ボイスメールメッセージの配送に特定のアドレシング要件をもたらすユーザに入口ランプ/出口ランプを使用できるのは望ましいです、[SELECTOR]で定義されたサービスセレクタに基づいて。 VPIM Addressingドキュメント[ADDRESS]で音声メールのための要件を扱うさらなる議論を見つけることができます。

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

受取人のE.164電話番号とSMTPメールボックスアドレスの間で写像するディレクトリサービスの使用を可能にするのは望ましいです。 これがENUMインフラストラクチャを使用することでどう達成されるかもしれないかについての議論が[VPIMENUM]にあります。 システムが使用するVPIM LDAP図式の定義は[SCHEMA]で見つけられます。

   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]あたりの元の形式で保存されるかもしれません。

6.  Notifications

6. 通知

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

配送Status Notificationsをサポートしなければなりません。 要求されるなら[DSN、DSN2、DSN3、DSN4]、メッセージのすべての非配送がNDNをもたらさなければなりません。 受電方式が満足している臨界をサポートして、音声メール(満足している臨界で、示される)の中で重要なメディアタイプを皆、処理できないならそうしなければならない、非、配送、[CRITICAL]あたりの全体のメッセージ。

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

Disposition Notifications SHOULDを通信させてください。[MDN]単位でサポートされます(MDN規則に従って、MDNsが返されるかどうか決めるオプションをユーザに与えなければなりません)。

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

受取人はコンポーネントが示した示された重要な内容のすべてを表示できないで、次に、それはSHOULDです。適切なMDNを返すオプションをユーザに与えてください([CRITICAL]を見てください)。

McRae & Parsons             Standards Track                     [Page 4]

RFC 4239                Internet Voice Messaging           November 2005

2005年11月に通信するマクレーと教区牧師標準化過程[4ページ]RFC4239インターネット声

7.  Voice Contents

7. 声のコンテンツ

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

音声メールをメッセージの中にどんな位置にも保管されるかもしれなくて、オーディオ的、または、基本的なcontent typeでいつも保管しなければなりません、創始者が受取人が他の内容を扱うことができるのを意識していない場合。 受取人が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]SHOULDからのContent-気質問題(声のメッセージ内容と異なるとしての)に関するVOICEパラメタ。 井戸、Content-持続時間ヘッダー[DUR]SHOULD、使用されて、オーディオの長さを示してください。

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

創始者の話された名前は別々のオーディオとしてコンテンツであって、知られているメッセージ、およびSHOULDと共に含まれるかもしれません。Content-気質VOICEパラメタで、VPIM v2[VPIMV2R2]で定義されるように、示されてください。 また、メッセージのための独身の受取人がいれば、話された名前は含まれるかもしれません(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].

送付実装は、メッセージを送る前に、受取人能力を決定して、それに従って(例えば、何らかの形式の満足している交渉を使用する)、コーデックを選ぶかもしれません。 そのような受取人知識がないとき、送付実装は生のG.711μ法を使用しなければなりません。(それは、「オーディオ的か基本的である」(SHOULDは".au"を終わらせるファイル名パラメタを使用する)[G711][MIME2]のMIME content typeで示されます)。 送付実装はVPIM v2[VPIMV2R2]と共に相互運用性をサポートするかもしれません、その場合、G.726(オーディオ/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μ法のメッセージをプレーできなければならなくて、VPIM v2を相互運用性に提供するために、G.726(オーディオ/32kadpcmとして、示される)をプレーできるかもしれません。 また、受信実装は他のコーデック(ネイティブかコード変換を通した)でコード化されたメッセージをプレーできるかもしれません。

   These requirements may be summarized as follows:

これらの要件は以下の通りまとめられるかもしれません:

   Codec           No VPIM v2 Support      With VPIM v2 Support
                   Record    Playback      Record      Playback
   -------------   ------    --------      ------      --------

コーデックノー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

5月がそうしなければならないMUST MUST MUST MUST G.726*がそうしなければならないG.711μ法Other*5月*5月

      * = MUST NOT, but MAY only if recipient capabilities known

* = 受取人能力である場合にだけ知られていた状態でそうしなければならないかもしれません。

McRae & Parsons             Standards Track                     [Page 5]

RFC 4239                Internet Voice Messaging           November 2005

2005年11月に通信するマクレーと教区牧師標準化過程[5ページ]RFC4239インターネット声

8.  Fax Contents

8. ファックスコンテンツ

   Fax contents SHOULD be carried according to RFC 2532 [IFAX].

ファックスでSHOULDをコンテンツに送ってください。RFC2532[IFAX]に従って、運ばれてください。

9.  Interoperability with VPIM v2

9. VPIM v2がある相互運用性

   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つの主要な選択肢について議論します。

9.1.  Handling VPIM v2 Messages in an IVM Client

9.1. IVM Clientの取り扱いVPIM v2 Messages

   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-conformantクライアントが複合かメッセージを声に出す(複合か混ぜられるとしてそれを扱うのによる)content typeを処理して、プレーできるなら、G.726はそれ(オーディオ/32kadpcmのcontent typeで、示される)の中でオーディオメッセージをコード化して、次に、受取人はそのデスクトップに発送される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).

conformant IVM実装はVPIM v2システムであることを知ることに非VPIM v2メッセージを送ってはいけません、また、目的地システムがそのようなメッセージを扱うことができるのを知らない場合(VPIM v2システムが優しい物腰で非VPIM v2メッセージを扱うよう奨励されますが)。 一般に、あなたがシステムがconformant 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.

さらに、IVMクライアントが完全にVPIM v2に従うかもしれないというわけではないことに注意されるべきです、プレーがG.726メッセージであるとサポートしても(例えば、それはVPIM v2によって必要とされたSensitivity分野の取り扱いを尊敬しないかもしれません)。 これはVPIM v2システムが彼らがVPIM v2対応であることを知らないどんなシステムにもメッセージを発送しないのを選ぶかもしれない1つの理由です。

9.2.  Dual Mode Systems and Clients

9.2. デュアル・モードシステムとクライアント

   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

また、IVM対応することのメッセージをサポートすることができるようにVPIM v2システムを拡張できました、そして、VPIM v2が言いなりになった状態で対応するとき、全部のVPIM v2を実装するためにIVM conformantクライアントを広げることができました。

McRae & Parsons             Standards Track                     [Page 6]

RFC 4239                Internet Voice Messaging           November 2005

2005年11月に通信するマクレーと教区牧師標準化過程[6ページ]RFC4239インターネット声

   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.

システム。 これは単に両方の仕様を履行して、適切なものを選択する問題です、受信されたメッセージ内容か受取人の能力によって。 利用対象者の能力が決定できるなら、これは関連システムのために最大限のインターオペラビリティを提供します。

   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システムかクライアントを使用しているかどうか決定するためのメカニズムがこの仕様の範囲の外にあることに注意してください。 能力発見のためのこの問題に適用できた様々なメカニズムは存在していますが、標準液は全くまだ定義されていません。

9.3.  Gateways

9.3. ゲートウェイ

   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.

1セットのVPIM v2ユーザを1セットの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.

例えば、兵士のSensitivityがあるVPIM v2メッセージはIVM受取人に送りにされるの代わりに拒絶されるかもしれません、兵士のメッセージの意味論を実装しないかもしれないので、CRITICALのCriticalityと共にVPIM v2(例えば、PNGイメージ)でサポートされなかった内容を含むIVMメッセージはゲートウェイで拒絶されるでしょうが。

   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]であると完全に実装しなければなりません、それらを超えた特定の創始者/受取人サポート能力がこれらの規格が必要であることをどうにか知らない場合。

10.  Security Considerations

10. セキュリティ問題

   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つの例がそうです。 これはゲートウェイを通した予期していなかった振舞いに通じるかもしれません。

   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.

さらに、ゲートウェイはメッセージシステムに感染したがっていたもののために攻撃の追加ポイントを提示します。 ゲートウェイが感染されるなら、感染しているゲートウェイから行われた「中央の猿」攻撃は認可された変換であるように検出するか、または見えるのが難しいかもしれません。

McRae & Parsons             Standards Track                     [Page 7]

RFC 4239                Internet Voice Messaging           November 2005

2005年11月に通信するマクレーと教区牧師標準化過程[7ページ]RFC4239インターネット声

   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]とこのドキュメントによって参照をつけられる他のRFCsで特定されたものを超えていないと予期されます--特にSMTP[DRUMSMTP]、インターネットMessage Format[DRUMSIMF]、MIME[MIME2]、Critical Content[CRITICAL]、およびMessage Context[ヒント]。

11.  References

11. 参照

11.1.  Normative References

11.1. 引用規格

   [ADDRESS]    Parsons, G., "Voice Profile for Internet Mail (VPIM)
                Addressing", RFC 3804, June 2004.

[アドレス]教区牧師、G.、「インターネットメール(VPIM)アドレシングのための声のプロフィール」、RFC3804、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] ボードルイ、G.、およびG.パーソンズ、「Quality Voiceに料金を課してください--32kbit/s Adaptive Differentialパルスコードの変調(ADPCM)MIME Sub-タイプRegistration」、RFC3802、2004年6月。

   [BEHAVIOUR]  Parsons, G. and J. Maruszak, "Voice Messaging Client
                Behaviour", RFC 4024, July 2005.

[ふるまい] パーソンズとG.とJ.Maruszak、「声のメッセージングクライアントのふるまい」、RFC4024、2005年7月。

   [CLID]       Parsons, G. and J. Maruszak, "Calling Line
                Identification for Voice Mail Messages", RFC 3939,
                December 2004.

[CLID] パーソンズとG.とJ.Maruszak、「線をボイスメールメッセージのための識別と呼びます」、RFC3939、2004年12月。

   [CRITICAL]   Burger, E., "Critical Content Multi-purpose Internet
                Mail Extensions (MIME) Parameter", RFC 3459, January
                2003.

[重要な] バーガー、E.、「重要な満足している多目的のインターネットメール拡大(MIME)パラメタ」、RFC3459、2003年1月。

   [DSN]        Moore, K., "Simple Mail Transfer Protocol (SMTP) Service
                Extension for Delivery Status Notifications (DSNs)", RFC
                3461, January 2003.

[DSN]ムーア、K.、「配送状態通知(DSNs)のためのシンプルメールトランスファプロトコル(SMTP)サービス拡大」、RFC3461、2003年1月。

   [DSN2]       Vaudreuil, G., "The Multipart/Report Content Type for
                the Reporting of Mail System Administrative Messages",
                RFC 3462, January 2003.

[DSN2] ボードルイ、G.、「メールのシステムの管理メッセージの報告のための複合/レポートcontent type」、RFC3462、2003年1月。

   [DSN3]       Vaudreuil, G., "Enhanced Mail System Status Codes", RFC
                3463, January 2003.

[DSN3] ボードルイ、G.、「高められたメールシステムステータスコード」、RFC3463、2003年1月。

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

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

   [DRUMSMTP]   Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
                April 2001.

[DRUMSMTP] Klensin、J.、「簡単なメール転送プロトコル」、RFC2821、2001年4月。

McRae & Parsons             Standards Track                     [Page 8]

RFC 4239                Internet Voice Messaging           November 2005

2005年11月に通信するマクレーと教区牧師標準化過程[8ページ]RFC4239インターネット声

   [DRUMSIMF]   Resnick, P., "Internet Message Format", RFC 2822, April
                2001.

[DRUMSIMF] レズニック、P.、「インターネットメッセージ・フォーマット」、RFC2822、2001年4月。

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

[DUR] ボードルイとG.とG.パーソンズ、「満足している持続時間MIMEヘッダー定義」、RFC3803、2004年6月。

   [HINT]       Burger, E., Candell, E., Eliot, C., and G. Klyne,
                "Message Context for Internet Mail", RFC 3458, January
                2003.

[暗示します] 2003年1月のバーガーとE.とCandellとE.とエリオット、C.とG.Klyne、「インターネットメールのためのメッセージの文脈」RFC3458。

   [IFAX]       Masinter, L. and D. Wing, " Extended Facsimile Using
                Internet Mail", RFC 2532, March 1999.

[IFAX] Masinter、L.、およびD.は1999年3月に「拡張ファクシミリはインターネットメールを使用すること」でのRFC2532に翼をつけさせます。

   [KEYWORDS]   Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119, March 1997.

[KEYWORDS]ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

   [MDN]        Hansen, T. and G. Vaudreuil, "Message Disposition
                Notification", RFC 3798, May 2004.

[MDN] ハンセン、T.、およびG.ボードルイ(「メッセージ気質通知」、RFC3798)は2004がそうするかもしれません。

   [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)は1つを分けます」。 「インターネットメッセージ本体の形式」、RFC2045、1996年11月。

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

解放された[MIME2]、N.、およびN.Borenstein、「マルチパーパスインターネットメールエクステンション(MIME)は2を分けます」。 「メディアタイプ」、RFC2046、1996年11月。

   [MIME5]      Freed, N. and N. Borenstein, "Multipurpose Internet Mail
                Extensions (MIME) Part Five: Conformance Criteria and
                Examples", RFC 2049, November 1996.

解放された[MIME5]、N.、およびN.Borenstein、「マルチパーパスインターネットメールエクステンション(MIME)は5を分けます」。 「順応評価基準と例」、RFC2049、11月1996日

   [SELECTOR]   Allocchio, C., "Minimal GSTN address format in Internet
                Mail", RFC 3191, October 2001.

[SELECTOR] Allocchio、C.、「インターネットメールにおける最小量のGSTNアドレス形式」、RFC3191、2001年10月。

   [SCHEMA]     Vaudreuil, G., "Voice Messaging Directory Service", RFC
                4237, October 2005.

[図式] ボードルイ、G.、「声のメッセージングディレクトリサービス」、RFC4237、2005年10月。

   [VPIMENUM]   Vaudreuil, G., "Voice Message Routing Service", RFC
                4238, October 2005.

[VPIMENUM] ボードルイ、G.、「音声メールルート設定サービス」、RFC4238、2005年10月。

   [VPIMV2]     Vaudreuil, G. and G. Parsons, "Voice Profile for
                Internet Mail -  version 2", RFC 2421, September 1998.

[VPIMV2] ボードルイ、G.、およびG.パーソンズは「バージョン2インチ、RFC2421、1998年インターネットメール--9月のためにProfileを声に出します」。

   [VPIMV2R2]   Vaudreuil, G. and G. Parsons, "Voice Profile for
                Internet Mail - version 2 (VPIMv2)", RFC 3801, June
                2004.

[VPIMV2R2] ボードルイ、G.、およびG.パーソンズ、「インターネットメールのためにProfileを声に出してください--バージョン2(VPIMv2)」、RFC3801、6月2004日

McRae & Parsons             Standards Track                     [Page 9]

RFC 4239                Internet Voice Messaging           November 2005

2005年11月に通信するマクレーと教区牧師標準化過程[9ページ]RFC4239インターネット声

11.2.  Informative References

11.2. 有益な参照

   [GOALS]      Candell, E., "High-Level Requirements for Internet Voice
                Mail", RFC 3773, June 2004.

[目標]Candell、E.、「インターネットボイスメールのためのハイレベルの要件」、RFC3773、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 Recommendation G.726(1990)、Digital Transmission Systems、Terminal EquipmentのAspects司令官--40、32、24、16kbit/s Adaptive Differentialパルスコードの変調(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

スチュアートJ.マクレーIBMロータス公園、<ステーンズ、土手道TW18 3AGイギリス

   Phone: +44 1784 445 112
   Fax: +44 1784 499 112
   EMail: stuart.mcrae@uk.ibm.com

以下に電話をしてください。 +44 1784 445 112、Fax: +44 1784 499 112はメールされます: stuart.mcrae@uk.ibm.com

   Glenn W. Parsons
   Nortel Networks
   3500 Carling Avenue
   Ottawa, ON K2H 8E9
   Canada

グレンW.ノーテル教区牧師はK2H8の9Eのカナダに3500縦梁Avenueオタワをネットワークでつなぎます。

   Phone: +1-613-763-7582
   Fax: +1-613-967-5060
   EMail: gparsons@nortel.com

以下に電話をしてください。 +1-613-763-7582 Fax: +1-613-967-5060 メールしてください: gparsons@nortel.com

McRae & Parsons             Standards Track                    [Page 10]

RFC 4239                Internet Voice Messaging           November 2005

2005年11月に通信するマクレーと教区牧師標準化過程[10ページ]RFC4239インターネット声

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (2005).

Copyright(C)インターネット協会(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.

このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。

   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.

このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。

   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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

   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機能のための基金は現在、インターネット協会によって提供されます。

McRae & Parsons             Standards Track                    [Page 11]

マクレーと教区牧師標準化過程[11ページ]