RFC3773 日本語訳

Network Working Group                                         E. Candell
Request for Comments: 3773                                      Comverse
Category: Informational                                        June 2004

Candellがコメントのために要求するワーキンググループE.をネットワークでつないでください: 3773年のComverseカテゴリ: 情報の2004年6月

            High-Level Requirements for Internet Voice Mail

インターネットボイスメールのためのハイレベルの要件

Status of this Memo

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

Copyright(C)インターネット協会(2004)。

Abstract

要約

   This document describes the high-level requirements for Internet
   Voice Mail (IVM) and establishes a baseline of desired functionality
   against which proposed MIME profiles for Internet Voice Messaging can
   be judged.  IVM is an extension of the Voice Profile for Internet
   Mail (VPIM) version 2 designed to support interoperability with
   desktop clients.  Other goals for this version of VPIM include
   expanded interoperability with unified messaging systems, conformance
   to Internet standards, and backward compatibility with voice
   messaging systems currently running in a VPIM enabled environment.
   This document does not include goals that were met fully by VPIM
   version 2.

このドキュメントは、インターネットVoiceメール(IVM)のためのハイレベルの要件について説明して、インターネットVoice Messagingのための提案されたMIMEプロフィールを判断できる必要な機能性の基線を確立します。 IVMはデスクトップクライアントと共に相互運用性をサポートするように設計されたインターネットメール(VPIM)バージョン2のためのVoice Profileの拡大です。 VPIMのこのバージョンの他の目標はユニファイド・メッセージングシステムがある拡張相互運用性を含んでいます、インターネット標準への順応、そして、現在VPIMへ駆け込む声のメッセージシステムとの後方の互換性が環境を可能にしました。 このドキュメントはVPIMバージョン2によって完全に達成された目標を含んでいません。

1.  Introduction

1. 序論

   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)のためのVoice Profileなどの規格はインターネットの上のそのようなシステムの間の相互運用性を可能にします。 VPIMバージョン1[VPIM1]は、実験的であり、インターネットメールのためのVoice Profileへの最初の試みでしたが、現在、Historicalとして分類されます。 VPIMバージョン2[VPIM2]は元々声のメッセージシステムだけの間に相互運用性を提供することを意図したVPIMバージョン1より改良です。 それはIPメッセージングネットワークの上でSMTP[DRUMSMTP]とMIME[MIME1]を使用することでボイスメールの交換を標準化するメッセージングプロフィールについて説明します。

   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

デスクトップ箱の数が急速に成長していて、すぐデスクトップ電話の数にアプローチするので、デスクトップメールクライアントアプリケーションの要件を考えるのは不可欠です。

Candell                      Informational                      [Page 1]

RFC 3773          Requirements for Internet Voice Mail         June 2004

インターネットボイスメール2004年6月のためのCandellの情報[1ページ]のRFC3773要件

   (including, but not limited to, MIME-compliant email clients).  With
   the trend toward integration of voice mail and email through unified
   messaging (UM), it is now necessary to define a profile that supports
   the needs of desktop applications and unified messaging systems
   (including Internet Facsimile [EXFAX]).  This profile is being
   referred to as Internet Voice Mail (IVM).

(包含、他、MIME対応することのメールクライアント。) ユニファイド・メッセージング(UM)を通してボイスメールの統合に向かった傾向とメールがある状態で、デスクトップアプリケーションとユニファイド・メッセージングシステムの必要性をサポートするプロフィールを定義するのが現在、必要です(インターネットFacsimile[EXFAX]を含んでいて)。 このプロフィールはインターネットVoiceメール(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.

このドキュメントはインターネットVoiceメールの目標を定義します。 この規格はボイスメールシステムと、ユニファイド・メッセージングシステムと、Eメールサーバと、デスクトップクライアントアプリケーションの間の音声メールの置き換えをサポートするでしょう。 デスクトップクライアントアプリケーションは特定、そして、重要にIVMにおもしろいです。 また、このドキュメントは、ウェブクライアントからボイスメールへのアクセスを容易にすることによって、サービスプロバイダーの提供を広くするでしょう。

2.  Conventions used in this document

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

   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

Anの操作上のサービスが特定の機能「端末」を実行するシステムのサービスプロバイダー「アプリケーション」A使用で標準化過程のコミュニケーションアプリケーション「目標」An目的の終点を提供した「サービス」

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

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

3. Goals for Internet Voice Mail

3. インターネットボイスメールの目標

3.1.  Interoperability

3.1. 相互運用性

   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のプライマリ目標です。 プロフィールはボイスメールシステムと、ユニファイド・メッセージングシステムと、インターネットEメールサーバと、デスクトップクライアントアプリケーションの間の相互運用性を容易にしなければなりません。 そのような相互運用性はただ一つのメッセージでマルチメディアタイプを結合するシステムをサポートしなければなりません、レガシーボイスメールとメールシステムと同様に。その上、ボイスメール、ユニファイド・メッセージング、およびメールシステムの異なった能力を収容する能力を許容しなければならない、IVM MUST、インターネットファックス(拡張モード)提案された標準とファックス身体の部分を含むVPIMメッセージと互換性があってください。

Candell                      Informational                      [Page 2]

RFC 3773          Requirements for Internet Voice Mail         June 2004

インターネットボイスメール2004年6月のためのCandellの情報[2ページ]のRFC3773要件

   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 MUSTは以下に記載されたシステムの中で相互運用性をサポートします:

      - Desktop Email client applications
      - IVM-capable Voice Mail systems
      - IVM-capable unified messaging systems
      - Traditional email servers

- デスクトップメールクライアントアプリケーション--IVMできるVoiceメールシステム--IVMできるユニファイド・メッセージングシステム--伝統的なEメールサーバ

   IVM SHOULD also support interoperability with VPIM version 2 Voice
   Mail Systems.

また、IVM SHOULDはVPIMバージョン2VoiceメールSystemsと共に相互運用性をサポートします。

   IVM MUST include new functionality to facilitate access to voice mail
   messages from desktop applications.

IVM MUSTは、デスクトップアプリケーションからボイスメールメッセージへのアクセスを容易にするために新しい機能性を含んでいます。

   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.

総合的な相互運用性はすべてのメッセージ要素のために相互運用性を必要とします: メッセージの正当性に不可欠であると考えられた身体の部分はサポートしなければなりません。各システムSHOULDにおいて、フォームに提供しなければならなくて、すなわち、ユーザがアクセスしやすくて、状態コード[CODES]を理解しなければならないという、保存されて、不可欠の情報、および操作が標準であったなら、サポートされてください。

3.1.1.  Interoperability with Desktop Email Client Applications

3.1.1. デスクトップメールクライアントアプリケーションがある相互運用性

   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 MUSTはデスクトップと他のメールを閲読するデバイスからボイスメールメッセージへのアクセスをサポートする特徴を提供します。 また、ウェブはSHOULDにボイスメールにアクセスします。デスクトップから、サポートされます。

   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 SHOULD NOTは多量の処理能力を持つためにデスクトップメールアプリケーションを必要とします、そして、基準面実装は共同利用しなければなりません、複雑な処理を提供しないでも。 相互運用性をサポートするために、少なくとも1つの義務的なコーデックを定義しなければなりません。 義務的なコーデックSHOULDは広くそうです。デスクトップでは、利用可能です。 また、VPIMバージョン2システムがある相互運用性のために、IVMアプリケーションはVPIM v2の義務的なコーデックをサポートするかもしれません、32KADPCM[ADPCMとG726-32]。

   Any codecs included in the IVM specification SHOULD meet the
   following criteria:

IVM仕様SHOULDに含まれていたどんなコーデックも以下の評価基準を満たします:

      -  Availability on desktops: Codecs SHOULD be available on most
         platforms.

- デスクトップに関する有用性: コーデックSHOULD、ほとんどのプラットホームで利用可能であってください。

Candell                      Informational                      [Page 3]

RFC 3773          Requirements for Internet Voice Mail         June 2004

インターネットボイスメール2004年6月のためのCandellの情報[3ページ]のRFC3773要件

      -  Source code availability: Source code SHOULD be readily
         accessible.

- ソースコードの有用性: ソースコードSHOULDは容易にそうです。アクセスしやすい。

      -  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 SHOULDは低ビット伝送速度で多くのスペース/帯域幅を持っていないデバイス(すなわち、ワイヤレスの)にコーデックを指定します。

      -  Voice Over IP support: IVM SHOULD specify a codec that supports
         Voice over IP implementations.

- Over IPサポートを声に出してください: IVM SHOULDはボイス・オーバー 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.

創始者が受取人が他の内容を扱うことができるのを意識していない場合、基本のオーディオ/内容タイプで声のContentをいつも含まなければなりません。 他の形式の今後のサポートを可能にするために、IVM SHOULDはオーディオ形式の解釈を必要としないで使用されるコーデックの識別を提供します。 IVM MAYはIVM仕様で特定されないオーディオencodingsと形式に受取人のために送付者が最適のコード化を意識している環境と形式をサポートさせます。

   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 MAYはIVMオーディオのストリーミングをデスクトップにサポートします。 IVM MAYは、流れるのを容易にするために明らかに生のオーディオ以外の形式をサポートします。

   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 MUSTは音声メールでのテキスト身体の部分の包含を許容します。 重要な内容が特定されて、最小量の破棄が統治されるように長さが指定されているとき、IVM SHOULD NOTは明らかに他のメディアタイプを禁止します。

   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 SHOULDはメッセージの内容について説明する方法を定義します、どう内容にアクセスできるかを示して。

   Desktop implementation of IVM MUST support attachments of any media
   type.

どんなメディアタイプのIVM MUSTサポート付属のデスクトップ実装。

Candell                      Informational                      [Page 4]

RFC 3773          Requirements for Internet Voice Mail         June 2004

インターネットボイスメール2004年6月のためのCandellの情報[4ページ]のRFC3773要件

3.1.2.  Interoperability with IVM-capable Voice Messaging Systems

3.1.2. 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 SHOULDは、IVM声のメッセージシステムと他の対応するシステムの間の相互運用性をサポートするために、より複雑なシステムによってサポートされるかもしれない追加機能性のために、相互運用性を保証する最小のセットの必要な特徴を持っていて、また、支給を持っています。IVM MUSTは、能力差のためメッセージを提供できなかったのを示しながら不可欠の内容とステータスコード[CODES]を特定するためにメカニズムを定義します。

   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 SHOULDはVPIMバージョン2声のメッセージシステムを何らかのレベルの相互運用性に提供します。IVMシステムは、IVMとVPIMの間の最小量の相互運用性にバージョン2をサポートするために、VPIMバージョン2 32KADPCMコーデック[ADPCMとG726 32]を受けることができるかもしれなくて、優雅に、レガシー受電方式がIVMコーデックをサポートしないケースを扱わなければなりません。

3.1.3.  Interoperability with IVM-capable Unified Messaging Systems

3.1.3. 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 MUSTは異なったメディアタイプを含む身体の部分の包含をサポートします。 また、それは別のタイプに関するメッセージ(複合か混ぜられるように)、および別のタイプの付属を含むVPIMメッセージへの付属としてVPIMメッセージを含むメッセージを扱わなければなりません。

   To provide interoperability with systems that cannot handle a
   particular content type, IVM MUST provide a mechanism for identifying
   critical content and MAY define media specific status codes and
   strings to handle non-delivery of these body parts.

特定のcontent typeを扱うことができないシステム、IVM MUSTを相互運用性に提供するのは、重要な内容を特定するのにメカニズムを提供して、これらの身体の部分の非配送を扱うために特定の状態がコード化するメディアとストリングを定義するかもしれません。

Candell                      Informational                      [Page 5]

RFC 3773          Requirements for Internet Voice Mail         June 2004

インターネットボイスメール2004年6月のためのCandellの情報[5ページ]のRFC3773要件

3.1.4.  Interoperability with Traditional Email Servers

3.1.4. 伝統的なEメールサーバがある相互運用性

   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.

伝統的なEメールサーバはインライン内容として原文のメディアだけをサポートするものです。 IVM MUSTは現在のインターネット・メール環境で一貫して共同利用します。 IVMメッセージがユーザのメールボックスに到着するなら、IVM MUSTはメール・メッセージのために一般的なユーザ習慣を共同利用するメカニズムに提供します: 非オーディオ設備を使用するメッセージに関するデータベースにそれらを保存する、「再-トランスミッション」、推進、メールダイジェストの作成、および返答。

3.2.  Conformance to Existing Standards

3.2. 既存の規格への順応

   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.

- 制限: プロフィールSHOULDは既存のインターネット・メール規格にできるだけわずかな制限しか課しません。 特に、RFC2822[DRUMSIMF]のすべての要素を支えなければなりません、プロフィールが他のIVM目標を達成するのを防ぐものを除いて。

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

- 追加: プロフィールSHOULDは既存のインターネットメールにできるだけわずかな追加しか規格にしません。 それ、SHOULDはファイル拡張子などのデスクトップ関連の領域の既存のデスクトップコンベンションを固く守ります。 新しいMIMEの種類かサブタイプを定義するのが必要であるなら、IVM仕事グループSHOULDはデスクトップ環境において既に標準であることの、または、共用の用語を提案します。

3.3.  Backward Compatibility

3.3. 後方の互換性

   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.

このプロフィールSHOULDはこのプロフィールの目標を達成するのに必要である機能性が感染されないという範囲へのVPIMバージョン2を後方の互換性に提供します。 後方の互換性が可能でないところでは、IVM SHOULDは相互運用性から生じるIVMメッセージの取り扱い非配送のためにVPIMバージョン2システムと他のレガシーシステムで1人の極小集合の規則とステータスコードを提供して、定義します。

3.4.  Robustness

3.4. 丈夫さ

   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 MUST、MIMEを理解していないレガシーゲートウェイが存在する環境で、使用可能であってください。 メッセージがエイミスゲートウェイ[エイミス-Aとエイミス-D]を通り抜けるとき、コアの特徴と重要なデータを失ってはいけません。 IVM SHOULDはバッファリング能力を制限して、すべてのヘッダー情報をバッファリングできるというわけではない受取人デバイスとゲートウェイがある相互運用性を許容します。

Candell                      Informational                      [Page 6]

RFC 3773          Requirements for Internet Voice Mail         June 2004

インターネットボイスメール2004年6月のためのCandellの情報[6ページ]のRFC3773要件

3.5.  Security Considerations

3.5. セキュリティ問題

   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 MUSTサポートは、音声メールを認証する、そして/または、暗号化しました。 さらに、IVM MUSTはVPIM v2[VPIM2]、このドキュメントによって参照をつけられる他のRFCs、特にSMTP[DRUMSMTP]、インターネットMessage Format[DRUMSIMF]、およびMIME[MIME1]で特定された安全保障問題を固く守ります。

4.  References

4. 参照

4.1.  Normative References

4.1. 引用規格

   [ADPCM]    Vaudreuil, G. and G. Parsons, "Toll Quality Voice - 32
              kbit/s ADPCM: MIME Sub-type Registration", RFC 2422,
              September 1998.

[ADPCM] ボードルイ、G.、およびG.パーソンズ、「Quality Voiceに料金を課してください--32は/s ADPCMをkbitします」。 「MIMEサブタイプ登録」、RFC2422、1998年9月。

   [AMIS-A]   Audio Messaging Interchange Specifications (AMIS) - Analog
              Protocol Version 1, Issue 2, February 1992.

[エイミス-A] オーディオメッセージング置き換え仕様(アミ)--アナログのプロトコルバージョン1、問題2、1992年2月。

   [AMIS-D]   Audio Messaging Interchange Specifications (AMIS) -
              Digital Protocol Version 1, Issue 3 August 1993.

[エイミス-D] オーディオメッセージング置き換え仕様(アミ)--デジタルプロトコルバージョン1、問題1993年8月3日。

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

「高められたメールシステム状態はコード化する」[コード]ボードルイ、G.、RFC3463、2003年1月。

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

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

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

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

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

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

   [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 Recommendation G.726(1990)、Digital Transmission Systems、Terminal EquipmentのAspects司令官--40、32、24、16kbit/s Adaptive Differentialパルスコードの変調(ADPCM)。

   [MIME1]    Freed, N. and N. Borenstein, "Multipurpose Internet Mail
              Extensions (MIME) Part One: Format of Internet Message
              Bodies", RFC 2045, November 1996.

解放された[MIME1]、N.、およびN.Borenstein、「マルチパーパスインターネットメールエクステンション(MIME)は1つを分けます」。 「インターネットメッセージ本体の形式」、RFC2045、1996年11月。

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

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

   [VPIM2]    Vaudreuil, G. and G. Parsons, "Voice Profile for Internet
              Mail, Version 2", RFC 2421, September 1998.

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

Candell                      Informational                      [Page 7]

RFC 3773          Requirements for Internet Voice Mail         June 2004

インターネットボイスメール2004年6月のためのCandellの情報[7ページ]のRFC3773要件

4.2.  Informative References

4.2. 有益な参照

   [VPIM1]    Vaudreuil, Greg, "Voice Profile for Internet Mail", RFC
              1911, February 1996.

[VPIM1] ボードルイ、グレッグ、「インターネットメールのための声のプロフィール」、RFC1911、1996年2月。

   [VPIM3]    Silvestro, L. and R. Miles, "Goals for Voice Profile for
              Internet Mail, Version 3", Work in Progress, March 2000.

[VPIM3] 何マイルも、「インターネットメールのための声のプロフィールの目標(バージョン3インチ)は進歩、2000年3月に扱う」Silvestro、L.、およびR.。

5.    Acknowledgments

5. 承認

   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ダイアナ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のメンバーによって提供された入力とフィードバックはグループを扱います。

6.  Author's Address

6. 作者のアドレス

   Emily Candell
   Comverse
   200 Quannapowitt Parkway
   Wakefield, MA 01803
   Phone: +1-781-213-2324
   EMail: emily.candell@comverse.com

ウェークフィールド、MA 01803が電話をするエミリーCandell Comverse200Quannapowitt公園道路: +1-781-213-2324 メールしてください: emily.candell@comverse.com

Candell                      Informational                      [Page 8]

RFC 3773          Requirements for Internet Voice Mail         June 2004

インターネットボイスメール2004年6月のためのCandellの情報[8ページ]のRFC3773要件

7.  Full Copyright Statement

7. 完全な著作権宣言文

   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.

Copyright(C)インターネット協会(2004)。 このドキュメントは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機能のための基金は現在、インターネット協会によって提供されます。

Candell                      Informational                      [Page 9]

Candell情報です。[9ページ]