RFC3801 日本語訳
3801 Voice Profile for Internet Mail - version 2 (VPIMv2). G.Vaudreuil, G. Parsons. June 2004. (Format: TXT=118122 bytes) (Obsoletes RFC2421, RFC2423) (Status: DRAFT STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group G. Vaudreuil
Request for Comments: 3801 Lucent Technologies
Obsoletes: 2421 G. Parsons
Category: Standards Track Nortel Networks
June 2004
コメントを求めるワーキンググループG.ボードルイの要求をネットワークでつないでください: 3801 ルーセントテクノロジーズは以下を時代遅れにします。 2421年のG.教区牧師カテゴリ: 規格は2004年6月にノーテルネットワークを追跡します。
Voice Profile for Internet Mail - version 2 (VPIMv2)
インターネットメールのための声のProfile--バージョン2(VPIMv2)
Status of this Memo
この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 (2004).
Copyright(C)インターネット協会(2004)。
Abstract
要約
This document specifies a restricted profile of the Internet multimedia messaging protocols for use between voice processing server platforms. The profile is referred to as the Voice Profile for Internet Mail (VPIM) in this document. These platforms have historically been special-purpose computers and often do not have the same facilities normally associated with a traditional Internet Email-capable computer. As a result, VPIM also specifies additional functionality, as it is needed. This profile is intended to specify the minimum common set of features to allow interworking between conforming systems.
このドキュメントは音声処理サーバプラットホームの間の使用にインターネットマルチメディアメッセージング・プロトコルの制限されたプロフィールを指定します。プロフィールはインターネットメール(VPIM)のために本書ではVoice Profileと呼ばれます。 これらのプラットホームは、歴史的に専用計算機であり、しばしば通常、伝統的なインターネットメールできるコンピュータに関連している同じ施設を持っているというわけではありません。 その結果、また、それが必要であるようにVPIMは追加機能性を指定します。 このプロフィールが従うシステムの間で織り込むのを許容する最小の一般的なセットの特徴を指定することを意図します。
This document obsoletes RFC 2421 and describes version 2 of the profile with greater precision. No protocol changes were made in this revision. A list of changes from RFC 2421 are noted in Appendix F. Appendix A summarizes the protocol profiles of this version of VPIM.
このドキュメントは、より大きい精度でRFC2421を時代遅れにして、プロフィールのバージョン2について説明します。 プロトコル変更は全くこの改正で行われませんでした。 RFC2421からの変化のリストはAppendix F.に述べられます。Appendix AはVPIMのこのバージョンのプロトコルプロフィールをまとめます。
Vaudreuil & Parsons Standards Track [Page 1] RFC 3801 VPIMv2 June 2004
ボードルイと教区牧師標準化過程[1ページ]RFC3801VPIMv2 June 2004
Table of Contents
目次
1. Introduction...................................................3
1.1. Voice Messaging System Limitations.......................3
1.2. Design Goals.............................................4
1.3. Applicability for VPIM...................................5
2. Requirements Language..........................................5
3. Protocol Restrictions..........................................6
4. Voice Message Interchange Format...............................6
4.1. VPIM Message Addressing Formats..........................7
4.2. Message Header Fields....................................9
4.3. MIME Audio Content Descriptions.........................17
4.4. Voice Message Content Types.............................19
4.5. Other MIME Contents.....................................23
4.6. Delivery Status Notification (DSN)......................25
4.7. Message Disposition Notification (MDN)..................26
4.8. Forwarded Messages......................................26
4.9. Reply Messages..........................................27
5. Message Transport Protocol....................................27
5.1. Base SMTP Protocol......................................28
5.2. SMTP Service Extensions.................................28
5.3. ESMTP - SMTP Downgrading................................30
6. Directory Address Resolution..................................30
7. Management Protocols..........................................30
7.1. Network Management......................................31
8. Conformance Requirements......................................31
9. Security Considerations.......................................32
9.1. General Directive.......................................32
9.2. Threats and Problems....................................32
9.3. Security Techniques.....................................33
10. Normative References..........................................33
11. Acknowledgments...............................................36
12. Appendix A - VPIM Requirements Summary........................37
13. Appendix B - Example Voice Messages...........................43
14. Appendix C - Example Error Voice Processing Error Codes.......49
15. Appendix D - Example Voice Processing Disposition Types.......50
16. Appendix E - IANA Registrations...............................50
16.1. Voice Content-Disposition Parameter Definition.........51
16.2. Multipart/Voice-Message MIME Media Type Definition.....51
17. Appendix F - Change History: RFC 2421 (VPIM V2) To This Doc...53
18. Authors' Addresses............................................54
19. Full Copyright Statement......................................55
1. 序論…3 1.1. メッセージシステム制限を声に出してください…3 1.2. 目標を設計してください…4 1.3. VPIMのための適用性…5 2. 要件言語…5 3. 制限について議定書の中で述べてください…6 4. メッセージ置き換え形式を声に出してください…6 4.1. VPIMメッセージアドレス指定形式…7 4.2. メッセージヘッダーフィールド…9 4.3. オーディオ内容記述をまねてください…17 4.4. メッセージ内容を声に出してください…19 4.5. 他のMIMEコンテンツ…23 4.6. 配送状態通知(DSN)…25 4.7. メッセージ気質通知(MDN)…26 4.8. メッセージを転送します…26 4.9. 回答メッセージ…27 5. メッセージ転送プロトコル…27 5.1. 基地のSMTPは議定書を作ります…28 5.2. SMTPは拡大を修理します…28 5.3. ESMTP--SMTP格下げ…30 6. ディレクトリアドレス解決…30 7. 管理プロトコル…30 7.1. ネットワークマネージメント…31 8. 順応要件…31 9. セキュリティ問題…32 9.1. 一般指示…32 9.2. 脅威と問題…32 9.3. セキュリティのテクニック…33 10. 標準の参照…33 11. 承認…36 12. 付録A--VPIM要件概要…37 13. 付録B--例の音声メール…43 14. 付録C--例の誤り音声処理エラーコード…49 15. 付録D--例の音声処理気質タイプ…50 16. 付録E--IANA登録証明書…50 16.1. 満足している気質パラメタ定義を声に出してください…51 16.2. 複合の、または、メッセージを声に出しているMIMEメディアは定義をタイプします…51 17. 付録F--歴史を変えてください: このDocへのRFC2421(VPIM V2)…53 18. 作者のアドレス…54 19. 完全な著作権宣言文…55
Vaudreuil & Parsons Standards Track [Page 2] RFC 3801 VPIMv2 June 2004
ボードルイと教区牧師標準化過程[2ページ]RFC3801VPIMv2 June 2004
1. Introduction
1. 序論
MIME is the Internet multipurpose, multimedia-messaging standard. This document explicitly recognizes its capabilities and provides a mechanism for the exchange of various messaging technologies, primarily voice and facsimile.
MIMEは多目的で、マルチメディアを通信させるインターネット規格です。 このドキュメントは、様々なメッセージング技術、主として声、およびファクシミリの交換に明らかに能力を認識して、メカニズムを提供します。
Voice messaging evolved as telephone answering service into a full send, receive, and forward messaging paradigm with unique message features, semantics and usage patterns. Voice messaging was introduced on special purpose computers that interface to a telephone switch and provide call answering and voice messaging services. Traditionally, messages sent from one voice messaging system to another were transported using analog networking protocols based on DTMF signaling and analog voice playback. As the demand for networking increases, there was a need for a standard high-quality digital protocol to connect these machines. VPIM has successfully demonstrated its usefulness as this new standard. VPIM is widely implemented and is seeing deployment in customer networks. This document clarifies ambiguities found in the earlier specification and is consistent with implementation practice. The profile is referred to as Voice Profile for Internet Mail (VPIM) in this document.
満への留守番電話がユニークなメッセージ機能、意味論、および用法パターンがあるメッセージングパラダイムを送って、受けて、進めるのに従って、声のメッセージングは発展しました。 声のメッセージングは電話スイッチに接続して、呼び出し回答と音声メッセージングサービスを供給する専用計算機の上で紹介されました。 伝統的に、1つの声のメッセージシステムから別のものに送られたメッセージは、DTMFシグナリングとアナログの声の再生に基づくアナログのネットワーク・プロトコルを使用することで輸送されました。 ネットワークの需要が増加するのに従って、標準の高品質なデジタルプロトコルがこれらのマシンを接続する必要がありました。 VPIMはこの新しい規格として首尾よく有用性を示しました。 VPIMは広く実装されて、顧客ネットワークに展開が見えています。 このドキュメントは、以前の仕様で見つけられたあいまいさをはっきりさせて、実装習慣と一致しています。 プロフィールはインターネットメール(VPIM)のために本書ではVoice Profileと呼ばれます。
This document specifies a restricted profile of the Internet multimedia messaging protocols for use between voice processing server platforms. These platforms have historically been special- purpose computers and often do not have the same facilities normally associated with a traditional Internet Email-capable computer. As a result, VPIM also specifies additional functionality, as it is needed. This profile is intended to specify the minimum common set of features to allow interworking between conforming systems.
このドキュメントは音声処理サーバプラットホームの間の使用にインターネットマルチメディアメッセージング・プロトコルの制限されたプロフィールを指定します。これらのプラットホームは、歴史的に特別な目的コンピュータであり、しばしば通常、伝統的なインターネットメールできるコンピュータに関連している同じ施設を持っているというわけではありません。 その結果、また、それが必要であるようにVPIMは追加機能性を指定します。 このプロフィールが従うシステムの間で織り込むのを許容する最小の一般的なセットの特徴を指定することを意図します。
This document obsoletes RFC 2421 and describes VPIM version 2 of with greater precision. No protocol changes were made in this revision. A list of changes from RFC 2421 are noted in Appendix F. Appendix A summarizes the protocol profiles of this version of VPIM.
このドキュメントは、より大きい精度でRFC2421を時代遅れにして、VPIMバージョン2について説明します。 プロトコル変更は全くこの改正で行われませんでした。 RFC2421からの変化のリストはAppendix F.に述べられます。Appendix AはVPIMのこのバージョンのプロトコルプロフィールをまとめます。
1.1. Voice Messaging System Limitations
1.1. 声のメッセージシステム制限
The following are typical limitations of voice messaging platforms that were considered in creating this baseline profile.
↓これはこの基線プロフィールを作成する際に考えられた声のメッセージングプラットホームの典型的な制限です。
1) Text messages are not normally received and often cannot be
easily displayed or viewed. They can often be processed only via
text-to-speech or text-to-fax features not currently present in
many of these machines.
1) しばしば容易にテキスト・メッセージを通常、受け取らないで、表示するというわけではありませんし、また見ることができるというわけではありません。 特徴が現在これらのマシンの多くに提示しないテキストからテキストからスピーチか単にファックスでそれらをしばしば処理できます。
Vaudreuil & Parsons Standards Track [Page 3] RFC 3801 VPIMv2 June 2004
ボードルイと教区牧師標準化過程[3ページ]RFC3801VPIMv2 June 2004
2) Voice mail machines usually act as an integrated Message
Transfer Agent, Message Store and User Agent. There is typically
no relaying of messages. RFC822 header fields may have limited
use in the context of the limited messaging features currently
deployed.
2) 通常、ボイスメールマシンは統合Message Transferエージェント、Messageストア、およびUserエージェントとして務めます。 メッセージについて通常リレーしてはいけません。 RFC822ヘッダーフィールドは現在配布されている限られたメッセージング機能の文脈における使用を制限したかもしれません。
3) Voice mail message stores are generally not capable of
preserving the full semantics of an Internet message. As such,
use of a voice mail machine for gatewaying is not supported. In
particular, storage of recipient lists, "Received:" lines, and
"Message-ID:" may be limited.
3) 一般に、ボイスメールメッセージ店はインターネットメッセージの完全な意味論を保存できません。 そういうものとして、ボイスメールマシンのgatewayingする使用はサポートされません。 「受け取りました。」と、特に、受取人のストレージは記載します。 系列、「Message ID:」 制限されるかもしれなくなってください。
4) Internet-style distribution/exploder mailing lists are not
typically supported. Voice mail machines often implement only
local alias lists, with error-to-sender and reply-to-sender
behavior. Reply-all capabilities using a Cc list are not generally
available.
4) インターネットスタイル分配/発破器メーリングリストは通常サポートされません。 ボイスメールマシンはしばしば誤りから送付者と回答から送付者への振舞いでローカルの別名リストだけを実装します。 一般に、Ccリストを使用する回答すべて、能力は利用可能ではありません。
5) Error reports must be machine-parsable so that helpful
responses can be voiced to users whose only access mechanism is a
telephone.
5) エラー・レポートは、唯一のアクセス機構が電話であるユーザに役立っている応答を声に出すことができるくらいマシン「パー-可能」でなければなりません。
6) The voice mail systems generally limit address entry to 16 or
fewer numeric characters, and normally do not support alphanumeric
mailbox names. Alpha characters are not generally used for
mailbox identification, as they cannot be easily entered from a
telephone terminal.
6) ボイスメールシステムは、一般に、アドレスエントリーを16か、より少ない数字に制限して、通常、英数字のメールボックス名をサポートしません。 一般に、アルファキャラクタはメールボックス識別に電話端末から彼らに容易に入ることができないように使用されません。
It should be noted that newer systems are based natively on SMTP/MIME and do not suffer these limitations. In particular, some systems may support media other than voice and fax.
より新しいシステムがネイティブにSMTP/MIMEに基づいていて、これらの制限を受けないことに注意されるべきです。 特に、いくつかのシステムが声とファックス以外のメディアをサポートするかもしれません。
1.2. Design Goals
1.2. デザイン目標
It is a goal of this profile to make as few restrictions and additions to the existing Internet mail protocols as possible while satisfying the requirements for interoperability with current generation voice messaging systems. This goal is motivated by the desire to increase the accessibility to digital messaging by enabling the use of proven existing networking software for rapid development.
既存のインターネットへのわずかな制限と追加が現代の声のメッセージシステムに相互運用性のための要件を満たしている間可能であるとしてのプロトコルを郵送するとき、それは作るこのプロフィールの目標です。この目標は急速現像のためのソフトウェアをネットワークでつなぎながら立証された存在の使用を可能にすることによってデジタルメッセージングへのアクセシビリティを増強する願望によって動機づけられています。
This specification is intended for use on a TCP/IP network; however, it is possible to use the SMTP protocol suite over other transport protocols. The necessary protocol parameters for such use are outside the scope of this document.
この仕様はTCP/IPネットワークにおける使用のために意図します。 しかしながら、他のトランスポート・プロトコルの上でSMTPプロトコル群を使用するのは可能です。 このドキュメントの範囲の外にそのような使用のための必要なプロトコルパラメタがあります。
Vaudreuil & Parsons Standards Track [Page 4] RFC 3801 VPIMv2 June 2004
ボードルイと教区牧師標準化過程[4ページ]RFC3801VPIMv2 June 2004
This profile is intended to be robust enough to be used in an environment, such as the global Internet, with installed-base gateways that do not understand MIME. Full functionality, such as reliable error messages and binary transport, will require careful selection of gateways (e.g., via MX records) to be used as VPIM forwarding agents. Nothing in this document precludes use of general-purpose MIME email packages to read and compose VPIM messages. While no special configuration is required to receive VPIM conforming messages, some may be required to originate conforming structures.
このプロフィールが環境で使用されているほど強健であることを意図します、世界的なインターネットなどのように、MIMEを理解していないインストールされたベースゲートウェイで。 信頼できるエラーメッセージや2進の輸送などの完全な機能性は、ゲートウェイ(例えば、MX記録を通した)の厳選がVPIM小口運送業者として使用されるのを必要とするでしょう。 何も、VPIMメッセージを読んで、構成するために本書では汎用MIMEメールパッケージの使用を排除しません。 どんな特別な構成もメッセージを従わせるVPIMを受け取るのに必要でない間、或るものが、構造を従わせながら起因するのに必要であるかもしれません。
It is expected that a system administrator who can perform TCP/IP network configuration will manage a VPIM messaging system. When using facsimile or multiple voice encodings, it is suggested that the system administrator maintain a list of the capabilities of the networked mail machines to reduce the sending of undeliverable messages due to lack of feature support. Configuration, implementation and management of these directory-listing capabilities are local matters.
TCP/IPネットワーク・コンフィギュレーションを実行できるシステム管理者がVPIMメッセージシステムを管理すると予想されます。 ファクシミリか複数の声のencodingsを使用するとき、システム管理者がネットワークでつながれたメールマシンが特徴サポートの不足のため「非-提出物」メッセージの発信を減少させる能力のリストを維持することが提案されます。 これらのディレクトリをリストアップする能力の構成、実装、および管理は地域にかかわる事柄です。
1.3. Applicability for VPIM
1.3. VPIMのための適用性
VPIM is intended for the exchange of voice messages between traditional voice messaging systems and for systems that need to interoperate with such systems. VPIM is intended connect voice- messaging systems into special-purpose voice messaging networks. VPIM may also be used between message store servers and VPIM-aware clients such as web servers, TUI, and GUI clients. VPIM is not intended or optimized for downloading to, or sending from commercial email clients.
VPIMは伝統的な声のメッセージシステムの間の音声メールの交換のために意図します、そして、そのようなシステムで. VPIMを共同利用する必要性がそうであるシステムには、意図して、専用声のメッセージングネットワークに声のメッセージシステムを関連づけてください。 また、VPIMはウェブサーバーや、TUIや、GUIクライアントなどのメッセージ店サーバとVPIM意識しているクライアントの間で使用されるかもしれません。 VPIMは、クライアントをダウンロードするか、または商業メールから送るために意図もしませんし、最適化もされません。
Internet Voice Messaging, the subject of a separate standards initiative, is intended to enable general-purpose email clients to send and receive voice content through general-purpose message stores in an interoperable way. IVM may also be a suitable format for downloading voice messages from a VPIM server to a commercial email client. It may also be a suitable format for submission of a voice message from a general-purpose client into a VPIM system.
インターネットVoice Messaging(別々の規格イニシアチブの対象)が、汎用メールクライアントが汎用メッセージ店を通して共同利用できる方法で声の内容を送って、受け取るのを可能にすることを意図します。 また、IVMは、VPIMサーバから商業メールクライアントまで音声メールをダウンロードするための適当な形式であるかもしれません。 また、それはVPIMシステムへの汎用クライアントからの音声メールの服従のための適当な形式であるかもしれません。
2. Requirements Language
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 [REQ].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[REQ]で説明されるように本書では解釈されることであるべきですか?
Vaudreuil & Parsons Standards Track [Page 5] RFC 3801 VPIMv2 June 2004
ボードルイと教区牧師標準化過程[5ページ]RFC3801VPIMv2 June 2004
3. Protocol Restrictions
3. プロトコル制限
This protocol does not limit the number of recipients per message. Where possible, server implementations should not restrict the number of recipients in a single message. It is recognized that no implementation supports unlimited recipients, and that the number of supported recipients may be quite low.
このプロトコルは1メッセージあたりの受取人の数を制限しません。 可能であるところでは、サーバ実装がただ一つのメッセージの受取人の数を制限するべきではありません。 どんな実装も無制限な受取人をサポートしないで、サポートしている受取人の数がかなり下位であるかもしれないと認められます。
This protocol does not limit the maximum message length. Implementers should understand that some machines will be unable to accept excessively long messages. A mechanism is defined in [SIZE] to declare the maximum message size supported.
このプロトコルは最大のメッセージ長を制限しません。 Implementersは、いくつかのマシンが過度に長いメッセージを受け入れることができないのを理解しているはずです。 メカニズムは、サイズがサポートした最大のメッセージを宣言するために[SIZE]で定義されます。
The following sections describe the restrictions and additions to Internet mail protocols that are required to be conforming with this VPIM v2 profile. Though various SMTP, ESMTP and MIME features are described here, the implementer is referred to the relevant RFCs for complete details. The table in Appendix A summarizes the protocol details of this profile.
以下のセクションはこのVPIM v2プロフィールに従うのに必要であるインターネットメールプロトコルに制限と追加について説明します。 様々なSMTP、ESMTP、およびMIME機能はそうですが、ここで説明されていて、implementerはきわめて詳細な情報について関連RFCsを参照されます。 Appendix Aのテーブルはこのプロフィールのプロトコル細部をまとめます。
4. Voice Message Interchange Format
4. 音声メール置き換え形式
The voice message interchange format is a profile of the Internet Mail Protocol Suite. Any Internet Mail message containing the format defined in this section is referred to as a VPIM Message in this document. As a result, this document assumes an understanding of the Internet Mail specifications. Specifically, VPIM references components from the message format standard for Internet messages [RFC822], the Multipurpose Internet Message Extensions [MIME1-5], the X.400 gateway specification [X.400], and the delivery status and message disposition notifications [REPORT][DSN][DRPT][STATUS][MDN].
音声メール置き換え形式はインターネットメールプロトコルSuiteのプロフィールです。 このセクションで定義された書式を含むどんなインターネットメールメッセージも本書ではVPIM Messageと呼ばれます。 その結果、このドキュメントはインターネットメール仕様の理解を仮定します。 明確に、メッセージからのVPIM参照の部品はインターネットメッセージ[RFC822]、MultipurposeインターネットMessage Extensions[MIME1-5]、X.400ゲートウェイ仕様[X.400]、配送状態、およびメッセージ気質通知[REPORT]における標準[DSN]の[DRPT][STATUS][MDN]をフォーマットします。
MIME, introduced in [MIME1], is a general-purpose message body format that is extensible to carry a wide range of body parts. It provides for encoding binary data so that it can be transported over the 7-bit text-oriented SMTP protocol. This transport encoding (denoted by the "Content-Transfer-Encoding:" MIME field) is in addition to the audio encoding required to generate a binary object.
[MIME1]で紹介されたMIMEはさまざまな身体の部分を運ぶのにおいて広げることができる汎用メッセージボディー形式です。 それは7ビットのテキスト指向のSMTPプロトコルの上でそれを輸送できるようにバイナリ・データをコード化するのに提供されます。 この輸送コード化(「内容はコード化を移す」というMIME分野で、指示される)は2進のオブジェクトを生成するのに必要であるオーディオコード化に加えています。
MIME defines two transport-encoding mechanisms to transform binary
data into a 7-bit representation, one designed for text-like data
("Quoted-Printable"), and one for arbitrary binary data ("Base64").
While Base64 is dramatically more efficient for audio data, either
will work. Where binary transport is available, no transport
encoding is needed, and the data can be labeled as "Binary".
MIMEがバイナリ・データを7ビットの表現、テキストのようなデータ(「引用されて印刷可能な」)のために設計されたもの、および任意のバイナリ・データのための1つに変えるために2つの輸送をコード化するメカニズムを定義する、(「Base64")」 Base64によるオーディオデータには、より効率的であることで、劇的に、どちらかが働くということですが。 2進の輸送が利用可能であるところでは、輸送コード化でないのを必要とします、そして、「2進である」とデータをラベルできます。
Vaudreuil & Parsons Standards Track [Page 6] RFC 3801 VPIMv2 June 2004
ボードルイと教区牧師標準化過程[6ページ]RFC3801VPIMv2 June 2004
4.1. VPIM Message Addressing Formats
4.1. VPIMメッセージアドレス指定形式
VPIM addresses SHALL use the RFC 822 format based on the Domain Name System. This naming system has two components: the local part, used for username or mailbox identification; and the host part, used for global machine identification.
VPIMは、SHALL使用がドメインネームシステムに基づくRFC822形式であると扱います。 この命名システムには、2つのコンポーネントがあります: ユーザ名かメールボックス識別に使用される地方の部分。 そして、グローバルなマシン識別に使用されるホスト部分。
4.1.1. VPIM Addresses
4.1.1. VPIMアドレス
The local part of the address shall be a US-ASCII string uniquely identifying a mailbox on a destination system. For voice messaging, the local part SHALL be a printable string containing the mailbox ID of the originator or recipient. While alpha characters and long mailbox identifiers MAY be permitted, short numeric local parts SHOULD be used as most voice mail networks rely on numeric mailbox identifiers to retain compatibility with the limited 10-digit telephone keypad. As a result, some voice messaging systems may only be able to handle a numeric local part. The reception of alphanumeric local parts on these systems may result in the address being mapped to some locally unique (but confusing to the recipient) number or, in the worst case the address could be deleted making the message unreplyable. Additionally, it may be difficult to create messages on these systems with an alphanumeric local part without complex key sequences or some form of directory lookup (see 6). The use of the Domain Name System should be transparent to the user. It is the responsibility of the voice mail machine to lookup the fully- qualified domain name (FQDN) based on the address entered by the user (see 6).
アドレスの地方の部分は目的地システムの上で唯一メールボックスを特定する米国-ASCIIストリングになるでしょう。 声のために、メッセージング、地方はメールボックスを含んだ印刷可能なストリングが創始者か受取人のIDであったならSHALLを分けます。 アルファキャラクタと長いメールボックス識別子が受入れられて、短い数値地方のパートSHOULDであるかもしれない間、ほとんどのボイスメールネットワークが限られた10ケタの電話キーパッドとの互換性を保有するために数値メールボックス識別子を当てにするので、使用されてください。 その結果、いくつかの声のメッセージシステムが数値地方の部分を扱うことができるだけであるかもしれません。 これらのシステムにおける英数字の地方の部分のレセプションが何らかの局所的にユニークな(受取人に混乱させるのを除いて)数に写像されるアドレスをもたらすかもしれませんか、またはメッセージを非回答可能させながら、最悪の場合にはアドレスは削除できました。 さらに、英数字の地方の部分で複雑なキー順か何らかのフォームのディレクトリルックアップなしでこれらのシステムにメッセージを作成するのは難しいかもしれません(6を見てください)。 ユーザにとって、ドメインネームシステムの使用はわかりやすいはずです。 それは完全に適切なドメイン名(FQDN)がユーザによって入れられたアドレスに基礎づけたルックアップへのボイスメールマシンの責任(6を見る)です。
In the absence of a global directory, specification of the local part is expected to conform to international or private telephone numbering plans. It is likely that private numbering plans will prevail and these are left for local definition. However, it is RECOMMENDED that public telephone numbers be noted according to the international numbering plan described in [E.164]. The indication that the local part is a public telephone number is given by a preceding "+" (the "+" would not be entered from a telephone keypad, it is added by the system as a flag). Since the primary information in the numeric scheme is contained by the digits, other character separators (e.g., "-") may be ignored (i.e., to allow parsing of the numeric local mailbox) or may be used to recognize distinct portions of the telephone number (e.g., country code). The specification of the local part of a VPIM address can be split into the four groups described below:
グローバルなディレクトリがないとき、地方の部分の仕様が国際的であるか個人的な電話付番プランに従うと予想されます。 個人的な付番プランは広がるでしょう、そして、これらは地方の定義に残されそうです。 しかしながら、公衆電話番号が[E.164]で説明された国際的な付番計画通りに注意されるのは、RECOMMENDEDです。 前の「+」は地方の部分が公衆電話番号であるという指示を与えます(「+」は電話キーパッドから入られないで、それは旗としてシステムによって加えられます)。 数値体系における一次情報がケタによって含まれているので、他のキャラクタ分離符(例えば、「-」)は、無視されるかもしれないか(すなわち、数値地方のメールボックスを分析するのを許容する)、または電話番号の異なった部分を認識するのにおいて使用されているかもしれません(例えば、国名略号)。 VPIMアドレスの地方の部分の仕様を以下で説明された4つのグループに分けることができます:
1) mailbox number
- for use as a private numbering plan (any number of digits)
- e.g., 2722@lucent.com
1) 個人的な付番プラン(いろいろなケタ)としての使用のメールボックス番号 - 例えば、 2722@lucent.com
Vaudreuil & Parsons Standards Track [Page 7] RFC 3801 VPIMv2 June 2004
ボードルイと教区牧師標準化過程[7ページ]RFC3801VPIMv2 June 2004
2) mailbox number+extension
- for use as a private numbering plan with extensions
any number of digits, use of "+" as separator
- e.g., 2722+111@Lucent.com
2) 例えばいずれも付番するケタの拡大、分離符としての「+」の使用でプランに付番する兵卒としての使用のためのメールボックス数+拡大、2722+ 111@Lucent.com
3) +international number
- for international telephone numbers conforming to E.164
maximum of 15 digits
- e.g., +16137637582@vm.nortel.ca
3) +国際的である、15ケタのE.164最大に従う国際電話番号には、+ 例えば 16137637582@vm.nortel.ca に付番してください。
4) +international number+extension
- for international telephone numbers conforming to E.164
maximum of 15 digits, with an extension (e.g., behind a
PBX) that has a maximum of 15 digits.
- e.g., +17035245550+230@ema.org
4) それには、+ 国際電話番号のための国際的な数+拡大が15ケタのE.164最大に従って、拡大(例えば、PBXの後ろの)によって、最大15ケタがあります。 - 例えば、+17035245550+ 230@ema.org
Note that this address format is designed to be compatible with current usage within the voice messaging industry. It is not compatible with the addressing formats of RFCs 2303-2304. It is expected that as telephony services become more widespread on the Internet, these addressing formats will converge.
このアドレス形式が産業を通信させながら声の中で現在の用法と互換性があるように設計されていることに注意してください。 それはRFCs2303-2304のアドレス指定形式と互換性がありません。 電話サービスがインターネットで、より広範囲になるのに従ってこれらのアドレス指定形式が一点に集まると予想されます。
4.1.2. Special Addresses
4.1.2. 特別なアドレス
Special addresses to represent the sender are provided for compatibility with the conventions of Internet mail. These addresses do not use numeric local addresses, both to conform to current Internet practice and to avoid conflict with existing numeric addressing plans. Two special addresses are RESERVED for use as follows:
送付者の代理をする特別なアドレスをインターネット・メールのコンベンションとの互換性に提供します。 これらのアドレスは、ともに現在のインターネット習慣に従って、既存の数値アドレシングプランとの闘争を避けるのに数値ローカルのアドレスを使用しません。 2つの特別なアドレスが以下の使用のためのRESERVEDです:
postmaster@domain
postmaster@domain
By convention, a special mailbox named "postmaster" MUST exist on all systems. This address is used for diagnostics and should be checked regularly by the system manager. This mailbox is particularly likely to receive text messages, which is not normal on a voice-processing platform. The specific handling of these messages is an individual implementation choice.
コンベンションで、「郵便局長」という特別なメールボックスはすべてのシステムの上に存在しなければなりません。このアドレスは、病気の特徴に使用されて、定期的にシステム・マネージャによってチェックされるべきです。 このメールボックスは特にテキスト・メッセージを受け取りそうです(音声処理プラットホームで正常ではありません)。 これらのメッセージの特定の取り扱いは個々の実装選択です。
non-mail-user@domain
non-mail-user@domain
If a reply to a message is not possible, such as a telephone- answering message, then the special address "non-mail-user" SHOULD be used as the originator's address. Any text name such as "Telephone Answering", or the telephone number if it is available, is permitted. This special address is used as a token to indicate an unreachable originator. A conforming implementation MUST NOT permit a reply to an
メッセージには、次に、電話回答メッセージのような特別なアドレス「非メールのユーザ」可能なSHOULDが回答であるならありません。創始者のアドレスとして、使用されます。 どんなテキストも「電話回答」としてそのようなものを命名するか、電話番号は、それであるなら利用可能であり、受入れられます。 この特別なアドレスは、手の届かない創始者を示すのにトークンとして使用されます。 従う実装は回答を可能にしてはいけません。
Vaudreuil & Parsons Standards Track [Page 8] RFC 3801 VPIMv2 June 2004
ボードルイと教区牧師標準化過程[8ページ]RFC3801VPIMv2 June 2004
address from "non-mail-user". For compatibility with the installed base of mail user agents, implementations MUST reject the message when a message addressed to "non-mail-user" is received. The status code for such NDN's is 5.1.1 "Mailbox does not exist".
「非メールのユーザ」からのアドレス。 「非メールのユーザ」に扱われたメッセージが受信されているとき、メールユーザエージェントのインストールされたベースとの互換性のために、実装はメッセージを拒絶しなければなりません。 NDNのそのようなもののためのステータスコードはそうです。5.1 .1 「メールボックスは存在していません」。
Example:
例:
From: Telephone Answering <non-mail-user@mycompany.com>
From: Answering <non-mail-user@mycompany.com に電話をしてください、gt。
4.1.3. Distribution Lists
4.1.3. 発送先リスト
There are many ways to handle distribution list (DL) expansions and none are 'standard'. A VPIM implementation MAY support DLs. Using a simple alias is a behavior closest to what many voice mail systems do today and what is to be used with VPIM messages. A couple of important features that need special care when DLs are used are:
発送先リスト(DL)拡張を扱う多くの方法があります、そして、なにも'標準ではありません'。 VPIM実装はDLsをサポートするかもしれません。 簡単な別名を使用するのは、どんな多くのボイスメールシステムが今日、するか、そして、何がVPIMメッセージと共に使用されることになっていたらよいかの最も近くの振舞いです。 DLsが使用されているとき特別な注意を必要とする2、3の重要な特徴は以下の通りです。
Reply to the originator - (Address in the RFC822 "Reply-To:" or
"From" field)
Errors to the submitter - (Address in the MAIL FROM field of the
ESMTP exchange or the "Return-Path:"
RFC822 field)
創始者への回答--(RFC822「Reply-To」か“From"分野のアドレス) submitterへの誤り、-または、(ESMTP交換のMAIL FROM分野のアドレス、「: 」 RFC822がさばくリターンパス)
Some proprietary voice messaging protocols include only the recipient of the particular copy in the envelope and include no "header fields" except date and per-message features. Most voice messaging systems do not provide for "Header Information" in their messaging queues and only include delivery information. As a result, recipient information MAY be in either the "To:" or "Cc:" header fields. If all recipients cannot be presented then the recipient header fields SHOULD be omitted to indicate that an accurate list of recipients (e.g., for use with a reply-all capability) is not known.
いくつかの独占声のメッセージング・プロトコルは、特定のコピーの受取人だけの封筒を含んでいて、日付と1メッセージあたりの特徴以外に、「ヘッダーフィールド」は全く含んでいません。 ほとんどの声のメッセージシステムが、彼らが待ち行列を通信させる際に「ヘッダー情報」に備えて、配送情報を含んでいるだけではありません。 その結果、受取人情報が「To:」にあるかもしれません。 または、「Cc:」 ヘッダーフィールド。 すべての受取人がその時提示されて、受取人ヘッダーがSHOULDをさばくということであるはずがないなら省略されて、受取人(例えば、回答すべて、能力がある使用のための)の正確なリストが知られていないのを示してください。
4.2. Message Header Fields
4.2. メッセージヘッダーフィールド
Internet messages contain a header information block. This header block contains information required to identify the sender, the list of recipients, the message send time, and other information intended for user presentation. Except for specialized gateway and mailing list cases, header fields do not indicate delivery options for the transport of messages.
インターネットメッセージはヘッダー情報ブロックを含んでいます。 このヘッダーブロックは送付者を特定するのに必要である情報を含んでいて、受取人のリスト、メッセージはユーザプレゼンテーションのために意図する時間の、そして、他の情報を送ります。 専門化しているゲートウェイとメーリングリストケース以外に、ヘッダーフィールドはメッセージの輸送のための配送オプションを示しません。
Distribution list processors are noted for modifying or adding to the header fields of messages that pass through them. VPIM systems MUST be able to accept and ignore header fields that are not defined here.
発送先リストプロセッサは、それらを通り抜けるメッセージのヘッダーフィールドに変更するか、または加えるので、有名です。 VPIMシステムは、ここで定義されないヘッダーフィールドを、受け入れて、無視できなければなりません。
The following header lines are permitted for use with VPIM messages:
以下のヘッダー系列は使用のためにVPIMメッセージで受入れられます:
Vaudreuil & Parsons Standards Track [Page 9] RFC 3801 VPIMv2 June 2004
ボードルイと教区牧師標準化過程[9ページ]RFC3801VPIMv2 June 2004
4.2.1. From
4.2.1. from
SEND RULES
規則を送ってください。
The originator's fully qualified domain address (a mailbox address followed by the fully qualified domain name) MUST be present. Systems conforming with this profile SHOULD provide the text personal name of the voice message originator in a quoted phrase, if the name is available. Text names of corporate or positional mailboxes MAY be provided as a simple string. From: [RFC822]
創始者の完全に適切なドメインアドレス(完全修飾ドメイン名があとに続いたメールボックスアドレス)は存在していなければなりません。 このプロフィールSHOULDに従うシステムが音声メール創始者のテキスト個人名を引用された句に提供します、名前が利用可能であるなら。 簡単なストリングとして法人の、または、位置のメールボックスの原文名を提供するかもしれません。 From: [RFC822]
Example:
例:
From: "Joe S. User" <12145551212@mycompany.com>
From: 「ジョーS.ユーザ、「 <12145551212@mycompany.com 、gt;、」
From: Technical Support <611@serviceprovider.com>
From: 技術的な Support <611@serviceprovider.com 、gt。
From: Non-mail-user@myserver.mycompany.com
From: Non-mail-user@myserver.mycompany.com
Voice mail machines may not be able to support separate attributes for the "From:" header fields and the SMTP MAIL FROM, VPIM-conforming systems SHOULD set these values to the same address. Use of addresses different than those present in the "From:" header field address may result in unanticipated behavior.
ボイスメールマシンは「From:」のために別々の属性をサポートすることができないかもしれません。 ヘッダーフィールドとSMTP MAIL FROM、VPIM-従うシステムSHOULDは同じアドレスにこれらの値を設定します。 「From:」で出席しているそれらと異なったアドレスの使用 ヘッダーフィールドアドレスは思いがけない振舞いをもたらすかもしれません。
RECEIVE RULES
規則を受け取ってください。
The user listed in the "From:" field MUST be presented in the voice message envelope of the voice messaging system as the originator of the message, though the exact presentation is an implementation decision (e.g., the mailbox ID or the text name MAY be presented). The "From:" address SHOULD be used for replies (see 4.9).
「From:」に記載されたユーザ メッセージの創始者として声のメッセージシステムの音声メール封筒に分野を提示しなければなりません、正確なプレゼンテーションは実装決定(例えば、メールボックスIDか原文名が提示されるかもしれない)ですが。 「From:」 SHOULDを扱ってください。回答には、使用されてください(4.9を見てください)。
4.2.2. To
4.2.2. to
The "To:" field contains the recipient's fully-qualified domain address.
「To:」 分野は受取人の完全に適切なドメインアドレスを含んでいます。
Example:
例:
To: +12145551213@mycompany.com
To: + 12145551213@mycompany.com
SEND RULES
規則を送ってください。
There MAY be one or more "To:" fields in any message. Systems SHOULD provide a list of recipients only if all recipients are available.
1か、より多くの「To:」があるかもしれません。 どんなメッセージの分野。 すべての受取人が手があく場合にだけ、システムSHOULDは受取人のリストを提供します。
Vaudreuil & Parsons Standards Track [Page 10] RFC 3801 VPIMv2 June 2004
ボードルイと教区牧師標準化過程[10ページ]RFC3801VPIMv2 June 2004
Systems, such as gateways from protocols or legacy platforms that do not indicate the complete list of recipients, MAY provide a "To:" line. Because these systems cannot accurately enumerate all recipients in the "To:" headers, recipients SHOULD NOT be enumerated.
受取人の全リストを示さないプロトコルからのゲートウェイか遺産プラットホームなどのシステムは「To:」を提供するかもしれません。 立ち並んでください。 これらのシステムが正確に「To:」のすべての受取人を数え上げることができるというわけではないので ヘッダー、受取人SHOULD NOT、列挙されてください。
RECEIVE RULES
規則を受け取ってください。
Systems conforming to this profile MAY discard the addresses in the "To:" fields if they are unable to store the information. This would, of course, make a reply-to-all capability impossible. If present, the addresses in the "To:" field MAY be used for a reply message to all recipients.
このプロフィールに一致しているシステムは「To:」でアドレスを捨てるかもしれません。 分野はそれらであるなら情報を格納できません。 これで、すべてに関する回答能力はもちろん不可能になるでしょう。 プレゼント、「To:」のアドレスです。 分野は応答メッセージにすべての受取人に使用されるかもしれません。
4.2.3. Cc
4.2.3. cc
The "Cc:" field contains additional recipients' fully qualified domain addresses. Many voice mail systems maintain only sufficient envelope information for message delivery and are not capable of storing or providing a complete list of additional recipients.
「Cc:」 分野は追加受取人の完全に適切なドメインアドレスを含んでいます。 多くのボイスメールシステムは、追加受取人の全リストをメッセージ配送のために十分な封筒情報だけを保守して、格納できませんし、提供できません。
SEND RULES
規則を送ってください。
Conforming implementations MAY send "Cc:" lists if all recipients are known at the time of origination. If not, systems SHOULD omit the "Cc:" fields to indicate that the full list of recipients is unknown or otherwise unavailable. The list of disclosed recipients MUST NOT include undisclosed recipients (i.e., those sent via a blind copy).
実現を従わせると、「Cc:」は送られるかもしれません。 リストはすべての受取人であるなら創作時点で、知られています。 そうでなければ、システムSHOULDは「Cc:」を省略します。 受取人の完全リストが未知である、またはそうでなければ、入手できないのを示すために、さばきます。 明らかにされた受取人のリストは明かされていない受取人を含んではいけません(すなわち、ものは盲目のコピーで発信しました)。
Example:
例:
Cc: +12145551213@mycompany.com
Cc: + 12145551213@mycompany.com
RECEIVE RULES
規則を受け取ってください。
Systems conforming to this profile MAY add all the addresses in the "Cc:" field to the "To:" field, others MAY discard the addresses in the "Cc:" fields. If a list of "Cc:" addresses is present, these addresses MAY be used for a reply message to all recipients.
このプロフィールに一致しているシステムは「Cc:」ですべてのアドレスを加えるかもしれません。 「To:」への分野 分野、他のものは「Cc:」でアドレスを捨てるかもしれません。 分野。 aであるなら、「Cc:」について記載してください。 アドレスが存在している、これらのアドレスは応答メッセージにすべての受取人に使用されるかもしれません。
4.2.4. Date
4.2.4. 日付
The "Date:" field contains the date and time the message was sent by the originator.
「日付:」 分野はメッセージが創始者によって送られた日時を含んでいます。
SEND RULES
規則を送ってください。
The sending system MUST report the time the message was sent. The time zone MUST be present and SHOULD be represented in a four-digit
メッセージを送ったとき、送付システムは報告しなければなりません。 時間帯は、表されたコネが4ケタであったならプレゼントとSHOULDであるに違いありません。
Vaudreuil & Parsons Standards Track [Page 11] RFC 3801 VPIMv2 June 2004
ボードルイと教区牧師標準化過程[11ページ]RFC3801VPIMv2 June 2004
time zone offset, such as -0500 for North American Eastern Standard Time. This MAY be supplemented by a time zone name in parentheses, e.g., "-0700 (PDT)".
時間帯は米国東部標準時のノース・アメリカンのための-0500などのように相殺されました。 これは括弧の時間帯の名、例えば、「-0700(太平洋夏時間の)」によって補われるかもしれません。
Example:
例:
Date: Wed, 28 Jul 96 10:08:49 -0800 (PST)
日付: 水曜日、1996年7月28日10:08:49 -0800(太平洋標準時)です。
If the VPIM sender is relaying a message from a system that does not provide a time stamp, the time of arrival at the gateway system SHOULD be used as the date.
VPIM送付者が伝言を伝えているなら、ゲートウェイシステムSHOULDでタイムスタンプ、到着時刻を提供しないシステムから、日付として使用されてください。
RECEIVE RULES
規則を受け取ってください。
Conforming implementations SHOULD be able to convert [RFC822] date and time stamps into local time
実現SHOULDを従わせて、[RFC822]日時のスタンプを現地時間に変換できてください。
4.2.5. Sender
4.2.5. 送付者
The "Sender:" field contains the actual address of the originator if an agent on behalf of the author indicated in the "From:" field sends the message.
「送付者:」 分野は「From:」で示された作者を代表したエージェントであるなら創始者の絶対番地を含んでいます。 分野はメッセージを送ります。
SEND RULES
規則を送ってください。
This header field MAY be sent by VPIM-conforming systems.
VPIM-従うシステムはこのヘッダーフィールドを送るかもしれません。
RECEIVE RULES
規則を受け取ってください。
If the address in the "Sender:" field cannot be preserved in the recipient's message queues or in the next-hop protocol from a gateway, the field MAY be silently discarded.
中のアドレスである、「送付者:」 受取人のメッセージキューで分野を保持できませんか、またはゲートウェイからの次のホッププロトコルでは、分野は静かに捨てられるかもしれません。
4.2.6. Return-Path
4.2.6. リターンパス
The "Return-path:" field is added by the final delivering SMTP
server. If present, it contains the address from the MAIL FROM
parameter of the ESMTP exchange (see [RFC822]). Any error messages
resulting from the delivery failure MUST be sent to this address.
Note that if the "Return-path:" is null ("<>") (e.g., a call answer
message would have no return path) delivery status notifications MUST
NOT be sent.
「リターンパス:」 分野はSMTPサーバーを送る決勝で加えられます。存在しているなら、それはESMTP交換のMAIL FROMパラメタからのアドレスを含んでいます([RFC822]を見てください)。 配信障害から生じるどんなエラーメッセージもこのアドレスに送らなければなりません。 それに注意してください、「リターンパス:」 ヌルが(「<>」)(例えば、呼び出し答えメッセージには、リターンパスが全くない)であるという状態通知を送ってはいけない配送。
SEND RULES
規則を送ってください。
The originating system MUST NOT add this header.
由来しているシステムはこのヘッダーを加えてはいけません。
Vaudreuil & Parsons Standards Track [Page 12] RFC 3801 VPIMv2 June 2004
ボードルイと教区牧師標準化過程[12ページ]RFC3801VPIMv2 June 2004
RECEIVE RULES
規則を受け取ってください。
If the receiving system is incapable of storing the return path (or MAIL FROM) to be used for subsequent delivery errors (i.e., it is a gateway to a legacy system or protocol), the receiving system must otherwise ensure that further delivery errors don't happen. Systems that do not support the return path MUST ensure that at the time the message is acknowledged (i.e., when a DSN would be sent), the message is delivered to the recipient's ultimate mailbox. Non-Delivery notifications SHOULD NOT be sent after that final delivery.
受電方式がその後の配送誤りに使用されるために、リターンパス(または、MAIL FROM)を格納できないなら(すなわち、それは遺産システムかプロトコルへのゲートウェイです)、受電方式は、別の方法でさらなる配送誤りが起こらないのを確実にしなければなりません。 リターンパスを支持しないシステムは、メッセージが承認されるとき(すなわち、いつDSNを送るでしょうか)メッセージが受取人の究極のメールボックスに渡されるのを確実にしなければなりません。 非配送通知SHOULD NOT、その最終的な配送の後に送ってください。
4.2.7. Message-id
4.2.7. メッセージイド
The "Message-Id:" field contains a globally unique per-message identifier.
「メッセージイド:」 分野は1メッセージあたり1つのグローバルにユニークな識別子を含んでいます。
SEND RULES
規則を送ってください。
A globally unique message-id MUST be generated for each message sent from a VPIM-conforming implementation.
グローバルにユニークなメッセージイドはVPIM-従う実現から送られた各メッセージのために発生しなければなりません。
Example:
例:
Message-Id: <12345678@mycompany.com>
メッセージイド: <12345678@mycompany.com>。
RECEIVE RULES
規則を受け取ってください。
When provided in the original message, it MUST be used when sending a MDN. This identifier MAY be used for tracking and auditing. From [RFC822]
MDNを送るとき、オリジナルのメッセージに提供すると、それを使用しなければなりません。 この識別子は、追跡するのに中古で監査しているかもしれません。 from[RFC822]
4.2.8. Reply-To
4.2.8. 答えます。
If present, the "Reply-To:" header provides a preferred address to which reply messages should be sent (see 4.9). Typically, voice mail systems can only support one originator of a message so it is likely that this field will be ignored by the receiving system. From: [RFC822]
プレゼント、「Reply-To」です。 ヘッダーは応答メッセージが送られるべきである都合のよいアドレスを提供します(4.9を見てください)。 通常、ボイスメールシステムがメッセージの1人の創始者しか支持できないので、この分野は受電方式によって無視されそうでしょう。 From: [RFC822]
SEND RULES
規則を送ってください。
A conforming system SHOULD NOT send a "Reply-To:" header.
SHOULD NOTが「Reply-To」を送る従うシステム ヘッダー。
RECEIVE RULES
規則を受け取ってください。
If a "Reply-To:" field is present, a reply-to-sender message MAY be sent to the address specified (that is, in lieu of the address in the "From:" field). If the receiving system (e.g., multi-protocol
「Reply-To」です。 分野が存在している、指定された(すなわち、「From:」分野のアドレスの代わりに)アドレスに回答から送付者へのメッセージを送るかもしれません。 受電方式である、(例えば、マルチプロトコル
Vaudreuil & Parsons Standards Track [Page 13] RFC 3801 VPIMv2 June 2004
ボードルイと教区牧師標準化過程[13ページ]RFC3801VPIMv2 June 2004
gateway) only supports one address for the originator, then the address in the "From:" field MUST be used and the "Reply-To:" field MAY be silently discarded.
ゲートウェイ) そして、創始者のためのサポート1アドレスだけ、「From:」のアドレス 分野は、使用されていて「Reply-To」であるに違いありません。 分野は静かに捨てられるかもしれません。
4.2.9. Received
4.2.9. 受信します。
The "Received:" field contains trace information added to the beginning of a RFC822 message by MTAs. This is the only field that may be added by an MTA. Information in this header is useful for debugging when using an US-ASCII message reader or a header-parsing tool. From: [RFC822]
「受け取りました」 分野はMTAsによってRFC822メッセージの始まりに加えられたトレース情報を含んでいます。 これはMTAによって加えられるかもしれない唯一の分野です。 米国-ASCIIメッセージ読者かヘッダーを分析するツールを使用するとき、このヘッダーの情報はデバッグの役に立ちます。 From: [RFC822]
SEND RULES
規則を送ってください。
A VPIM-conforming system MUST add a "Received:" field. When acting as a gateway, information about the system from which the message was received SHOULD be included.
VPIM-従うシステムは「受け取ったこと」を加えなければなりません。 さばきます。 行動するときには、ゲートウェイ、メッセージが容認されたSHOULDであったシステムの情報として、含められてください。
RECEIVE RULES
規則を受け取ってください。
A VPIM-conforming system MUST NOT remove any "Received:" fields when relaying messages to other MTAs or gateways. These header fields MAY be ignored or deleted when the message is received at the final destination.
VPIM-従うシステムは少しも「受け取ったこと」を取り除いてはいけません。 他のMTAsかゲートウェイにメッセージをリレーするとき、さばきます。 最終的な目的地にメッセージを受け取るとき、これらのヘッダーフィールドを無視するか、または削除するかもしれません。
4.2.10. MIME Version
4.2.10. MIMEバージョン
The "MIME-Version:" field MUST be present to indicate that the message conforms to [MIME1-5]. Systems conforming with this specification SHOULD include a comment with the words "(Voice 2.0)". [VPIM1] defines an earlier version of this profile and uses the token (Voice 1.0). Example:
「MIMEバージョン:」 分野は、メッセージが[MIME1-5]に従うのを示すために存在していなければなりません。 この仕様SHOULDに従うシステムが「(声2.0)」という単語によるコメントを含んでいます。 [VPIM1]は、このプロフィールの以前のバージョンを定義して、象徴(声1.0)を使用します。 例:
MIME-Version: 1.0 (Voice 2.0)
MIMEバージョン: 1.0 (声2.0)
This identifier is intended for information only and SHOULD NOT be used to semantically identify the message as being a VPIM message. Instead, the presence of the multipart/voice-message content type defined in section 18.2 SHOULD be used if identification is necessary.
この識別子は情報だけとSHOULD NOTのために意図します。使用されて、メッセージがVPIMメッセージであると意味的に認識してください。 代わりに、複合/音声メール内容の存在はタイプします。セクション18.2SHOULDで定義されて、識別が必要であるなら、使用されてください。
4.2.11. Content-Type
4.2.11. コンテントタイプ
The "Content-Type:" header MUST be present to declare the type of content enclosed in the message. The typical top-level content in a VPIM Message SHOULD be Multipart/Voice-Message. The allowable contents are detailed starting in section 4.4 of this document. From: [MIME2]
「コンテントタイプ:」 ヘッダーは、メッセージに同封された内容のタイプを宣言するために出席していなければなりません。 VPIM Message SHOULDの典型的なトップレベル内容はメッセージをMultipart/声に出します。 許容できる内容はこのドキュメントのセクション4.4で始まるのにおいて詳細です。 From: [MIME2]
Vaudreuil & Parsons Standards Track [Page 14] RFC 3801 VPIMv2 June 2004
ボードルイと教区牧師標準化過程[14ページ]RFC3801VPIMv2 June 2004
4.2.12. Content-Transfer-Encoding
4.2.12. 満足している転送コード化
Because Internet mail was initially specified to carry only 7-bit US-ASCII text, it may be necessary to encode voice and fax data into a representation suitable for that environment. The "Content- Transfer-Encoding:" header describes this transformation if it is needed.
インターネット・メールが初めは7ビットの米国-ASCIIテキストだけを運ぶために指定されたので、その環境に適した表現に声をコード化して、ファックスでデータを送るのが必要であるかもしれません。 「以下を転送でコード化する内容」 それが必要であるなら、ヘッダーはこの変化について説明します。
SEND RULES
規則を送ってください。
An implementation in conformance with this profile SHOULD send audio and/or facsimile data in "Binary" form when binary message transport is available (see section 5). When binary transport is not available, implementations MUST encode the audio and/or facsimile data as "Base64".
2進のメッセージ転送であるときにSHOULDが「2進」のフォームでオーディオ、そして/または、ファクシミリデータを送るこのプロフィールによる順応における実現は利用可能です(セクション5を見てください)。 2進の輸送が利用可能でないときに、実現は、オーディオをコード化する、そして/または、"Base64""としてデータを電送しなければなりません。
RECEIVE RULES
規則を受け取ってください。
Conforming implementations MUST recognize and decode the standard encodings, "Binary" (when binary support is available), "7bit, "8bit", "Base64" and "Quoted-Printable" per [MIME1]. The detection and decoding of "Quoted-Printable", "7bit", and "8bit" MUST be supported in order to meet MIME requirements and to preserve interoperability with the fullest range of possible devices.
実現を従わせるのは、標準のencodingsを認識して、解読しなければなりません、「2進である」、(2進のサポートが利用可能であるときに)「「8ビット」「[MIME1]あたりBase64"で「引用されて印刷可能」」7ビット MIME必要条件を満たして、最もふくよかな範囲の可能な装置で相互運用性を保存するために「引用されて印刷可能」の検出と解読、「7ビット」、および「8ビット」を支持しなければなりません。
4.2.13. Sensitivity
4.2.13. 感度
The "Sensitivity:" field, if present, indicates the requested privacy level. If no privacy is requested, this field is omitted. The header definition is as follows:
「感度:」 存在しているなら、分野は要求されたプライバシーレベルを示します。 プライバシーが全く要求されないなら、この分野は省略されます。 ヘッダー定義は以下の通りです:
Sensitivity := "Sensitivity" ":" Sensitivity-value
「感度:=「感度」」:、」 感度値
Sensitivity-value := "Personal" / "Private" / "Company-Confidential"
感度価値:=「個人的である」か「個人的な」/「社内秘密」
SEND RULES
規則を送ってください。
A VPIM-conforming implementation MAY include this header to indicate the sensitivity of a message. If a user marks a message "Private", a conforming implementation MUST send only the "Private" sensitivity level. There are no VPIM-specific semantics defined for the values "Personal" or "Company-Confidential". A conforming implementation SHOULD NOT send the values "Personal" or "Company-Confidential". If the message is of "Normal" sensitivity, this field SHOULD be omitted. From: [X.400]
VPIM-従う実現は、メッセージの感度を示すためにこのヘッダーを含むかもしれません。 ユーザが、メッセージが「個人的である」とマークするなら、従う実現は「個人的な」感度レベルだけを送らなければなりません。 値のために定義されたどんなVPIM特有の意味論も「個人的である」か「会社秘密」の状態でありません。 SHOULD NOTが値「個人的である」か「社内秘密」を送る従う実現。 これはメッセージが「正常な」感度のそうなら、SHOULDをさばきます。省略されます。 From: [X.400]
Vaudreuil & Parsons Standards Track [Page 15] RFC 3801 VPIMv2 June 2004
ボードルイと教区牧師標準化過程[15ページ]RFC3801VPIMv2 June 2004
RECEIVE RULES
規則を受け取ってください。
If a "Sensitivity:" field with a value of "Private" is present in the message, a conforming system MUST prohibit the recipient from forwarding this message to any other user. A conforming system, however, SHOULD allow the responder to reply to a sensitive message, but SHOULD NOT include the original message content. The responder MAY set the sensitivity of the reply message.
aである、「感度:」 「個人的」の値がある分野がメッセージに存在している、従うシステムはこのメッセージをいかなる他のユーザにも転送するのから受取人を禁じなければなりません。 しかしながら、従うシステムであり、SHOULDは機密のメッセージに応答者について答えさせますが、SHOULD NOTはオリジナルのメッセージ内容を含んでいます。 応答者は応答メッセージの感度を設定するかもしれません。
A receiving system MAY ignore sensitivity values of "Personal" and "Company Confidential".
受電方式は「個人的で」「会社秘密」の感度値を無視するかもしれません。
If the receiving system does not support privacy and the sensitivity is "Private", a negative delivery status notification MUST be sent to the originator with the appropriate status code (5.6.0) "Other or undefined protocol status" indicating that privacy could not be assured. The message contents SHOULD be returned to the sender to allow for a voice context with the notification. A non-delivery notification to a private message SHOULD NOT be tagged private since it will be sent to the originator. From: [X.400]
受電方式がプライバシーを支持しないで、感度が「個人的である」なら、否定的配送状態通知を適切なステータスコードをもっている創始者に送らなければならない、(5.6、.0、)、そのプライバシーを示す「他の、または、未定義のプロトコル状態」は保証できませんでした。 メッセージはSHOULDを満足させます。送付者に返して、通知で声の文脈を考慮してください。 それを創始者に送るので個人的にタグ付けをされていて、兵卒への非配送通知はSHOULD NOTを通信させます。 From: [X.400]
A message with no privacy explicitly noted (i.e., no header) or with "Normal" sensitivity has no special treatment.
明らかに注意されない(すなわち、ヘッダーがありません)プライバシーか全く「正常な」感度があるメッセージには、どんな特別な処理もありません。
4.2.14. Importance
4.2.14. 重要性
Indicates the requested importance to be given by the receiving system. If no special importance is requested, this header MAY be omitted and the value of the absent header assumed to be "normal". From: [X.400]
受電方式によって与えられる要求された重要性を示します。 どんな特別な重要性も要求されていて、このヘッダーが省略されるかもしれないということでないかどうか、そして、「正常である」と思われた欠けているヘッダーの値。 From: [X.400]
Importance := "Importance" ":" importance-value
「重要性:=「重要性」」:、」 重要性値
Importance-value := "low" / "normal" / "high"
重要性価値の:=「安値」/「標準」/「高値」
SEND RULES
規則を送ってください。
Conforming implementations MAY include this header to indicate the importance of a message.
実現を従わせると、このヘッダーは、メッセージの重要性を示すために包含するかもしれません。
RECEIVE RULES
規則を受け取ってください。
If the receiving system does not support "Importance:", the attribute MAY be silently dropped.
受信システムがどんなサポートもしない、「重要性:」、属性は静かに落とされるかもしれません。
Vaudreuil & Parsons Standards Track [Page 16] RFC 3801 VPIMv2 June 2004
ボードルイと教区牧師標準化過程[16ページ]RFC3801VPIMv2 June 2004
4.2.15. Subject
4.2.15. 対象
The "Subject:" field is often provided by email systems but is not widely supported on voice mail platforms. From: [RFC822]
「Subject:」 分野をしばしばメールシステムで提供しますが、ボイスメールプラットホームFrom:で広く支持しません。 [RFC822]
SEND RULES
規則を送ってください。
For compatibility with text-based mailbox interfaces, a text subject field SHOULD be generated by a conforming implementation. It is RECOMMENDED that voice-messaging systems that do not support any text user interfaces (e.g., access only by a telephone) insert a generic subject header of "VPIM Message" or "Voice Message" for the benefit of GUI-enabled recipients.
テキストベースとの互換性のために、メールボックスは連結して、テキスト対象分野はSHOULDです。従う実現で、発生します。 どんなテキストユーザインタフェース(例えば、電話だけによるアクセス)も支持しない声メッセージシステムがGUIによって可能にされた受取人の利益のための「VPIMメッセージ」か「音声メール」の総称的主語ヘッダーを挿入するのは、RECOMMENDEDです。
RECEIVE RULES
規則を受け取ってください。
It is anticipated that many voice-only systems will be incapable of storing the subject line. The subject MAY be discarded by a receiving system.
多くの音声だけシステムが件名を格納できないと予期されます。 対象は受電方式によって捨てられるかもしれません。
4.3. MIME Audio Content Descriptions
4.3. MIMEオーディオ内容記述
4.3.1. Content-Description
4.3.1. 満足している記述
This field MAY be present to facilitate the text identification of these body parts in simple email readers. Any values may be used.
この分野は、純真なメール読者でのこれらの身体の部分のテキスト識別を容易にするために存在しているかもしれません。 どんな値も使用されるかもしれません。
Example:
例:
Content-Description: Big Telco Voice Message
満足している記述: 大きい通信業者音声メール
SEND RULES
規則を送ってください。
This field MAY be added to a voice body part to offer a freeform description of the voice content. It is useful to incorporate the values for Content-Disposition with additional descriptions. For example, this can be used to indicate product name or transcoding records.
この分野は、声の内容の自由形状記述を提供するために声の身体の部分に加えられるかもしれません。 Content-気質のために追加記述で値を取り入れるのは役に立ちます。 例えば、製品名かコード変換記録を示すのにこれを使用できます。
RECEIVE RULES
規則を受け取ってください。
This field MAY be displayed to the recipient. However, since it is only informative it MAY be ignored.
この野原を受取人に表示するかもしれません。 しかしながら、有益であるだけであるので、それは無視されるかもしれません。
Vaudreuil & Parsons Standards Track [Page 17] RFC 3801 VPIMv2 June 2004
ボードルイと教区牧師標準化過程[17ページ]RFC3801VPIMv2 June 2004
4.3.2. Content-Disposition
4.3.2. 満足している気質
This field MUST be present to allow the parsable identification of body parts within a VPIM voice message. This is especially useful if, as is typical, more than one Audio/* body occurs within a single level (e.g., Multipart/Voice-Message). Since a VPIM voice message is intended to be automatically played in the order in which the audio contents occur, the audio contents MUST always be of disposition inline. However, it is still useful to include a filename value, so this SHOULD be present if this information is available. From: [DISP]
この分野は、VPIM音声メールの中で身体の部分の「パー-可能」識別を許すために存在していなければなりません。 典型的であることで、1つ以上のAudio/*ボディーがただ一つのレベル(例えば、声Multipart/メッセージ)の中にそのままで起こるなら、これは特に役に立ちます。 オーディオ内容が現れるオーダーでVPIM音声メールによって自動的にプレーされることを意図するので、いつもオーディオコンテンツは気質インラインのものであるに違いありません。 しかしながら、そのように、ファイル名値、このSHOULDを含むようにまだ役に立っているのが、プレゼントがこの情報であるなら利用可能であるということであるということです。 From: [DISP]
SEND RULES
規則を送ってください。
In order to distinguish between the various types of audio contents in a VPIM voice message a new disposition parameter "voice" is defined with IANA (see section 18.1) with the parameter values below to be used as appropriate:
VPIM音声メールの様々なタイプのオーディオコンテンツを見分けて、パラメタ値が以下にある状態で、「声」という新しい気質パラメタは適宜使用されるためにIANA(セクション18.1を見る)と共に定義されます:
Audio-Type := "voice" "=" Audio-type-value
オーディオのタイプ:=「声」はオーディオタイプ価値と「等しいです」。
Audio-type-value := "Voice-Message" / "Voice-Message-Notification" / "Originator-Spoken-Name" /"Recipient-Spoken-Name" /"Spoken-Subject"
オーディオタイプ価値の:=「音声メール」/「声のメッセージ通知」/「創始者の話された名」/「受取人の話された名」/「話された対象」
Voice-Message - the primary voice message,
Voice-Message-Notification - a spoken delivery notification
or spoken disposition notification,
Originator-Spoken-Name - the spoken name of the originator,
Recipient-Spoken-Name - the spoken name of the recipient(s) if
available to the originator
Spoken-Subject- the spoken subject of the message, typically
spoken by the originator
声メッセージ--第一の音声メール、話された配送通知の、または、話されたVoiceメッセージ通知気質通知、Originator、話された名前、--創始者の話された名前、Recipient、話された名前、--、受取人における名義の、しかし、創始者にとって、利用可能な話し、Spokenかけます。
Note that there SHOULD only be one instance of each of these types of audio contents per message level. Additional instances of a given type (i.e., parameter value) MAY occur within an attached forwarded or reply voice message. If there are multiple recipients for a given message, recipient-spoken-name MUST NOT be used.
そこでそれに注意してください、SHOULD、単にそれぞれのこれらのタイプのメッセージレベルあたりのオーディオコンテンツの1つの例になってください。 与えられたタイプ(すなわち、パラメタ値)の追加例は進められるか回答の添付の音声メールの中に起こるかもしれません。 与えられたメッセージのための複数の受取人がいれば、受取人の話された名を使用してはいけません。
RECEIVE RULES
規則を受け取ってください。
Implementations SHOULD use this header. However, those that do not understand the "voice" parameter (or the "Content-Disposition:" header) can safely ignore it, and will present the audio body parts in order (but will not be able to distinguish between them). If more than one instance of the "voice" parameter type value is encountered at one level (e.g., multiple 'Voice-Message' tagged contents) then they SHOULD be presented together.
実現SHOULDはこのヘッダーを使用します。 または、しかしながら、それがするものが「声」パラメタを理解していない、(「満足している気質:」 ヘッダー) 安全にそれを無視できて、整然とした状態でオーディオ身体の部分を提示するでしょう(しかし、それらを見分けることができないでしょう)。 「声」パラメータの型価値の1つ以上の例が1平らな(例えば、複数の'声メッセージ'タグ付けをされたコンテンツ)当時のそれらSHOULDで遭遇するなら、一緒に提示されてください。
Vaudreuil & Parsons Standards Track [Page 18] RFC 3801 VPIMv2 June 2004
ボードルイと教区牧師標準化過程[18ページ]RFC3801VPIMv2 June 2004
4.3.3. Content-Duration
4.3.3. 満足している持続時間
The "Content-Duration:" header provides an indication of the audio length in seconds of the segment.
「満足している持続時間:」 ヘッダーはセグメントの秒のオーディオの長さのしるしを供給します。
Example:
例:
Content-Duration: 33
満足している持続時間: 33
SEND RULES
規則を送ってください。
This field MAY be present to allow the specification of the length of the audio body part in seconds.
この分野は、秒のオーディオ身体の部分の長さの仕様を許容するために存在しているかもしれません。
RECEIVE RULES
規則を受け取ってください。
The use of this field on reception is a local implementation issue. From: [DUR]
レセプションにおけるこの分野の使用はローカルの導入問題です。 From: [DUR]
4.3.4. Content-Language:
4.3.4. 満足している言語:
This field MAY be present to allow the specification of the spoken language of the audio body part. The encoding is defined in [LANG].
この分野は、オーディオ身体の部分の話し言葉の仕様を許容するために存在しているかもしれません。 コード化は[ラング]で定義されます。
Example for UK English:
イギリスのイギリス人への例:
Content-Language: en-UK
満足している言語: アンイギリス
SEND RULES
規則を送ってください。
A sending system MAY add this field to indicate the language of the voice. The determination of this (e.g., automated or user-selected) is a local implementation issue.
送付システムは、声の言語を示すためにこの分野を加えるかもしれません。 この決断、(例えば、自動化されるかユーザによって選択される、)、ローカルの導入問題はそうです。
RECEIVE RULES
規則を受け取ってください。
The use of this field on reception is a local implementation issue. It MAY be used as a hint to the recipient (e.g., end-user or an automated translation process) as to the language of the voice message.
レセプションにおけるこの分野の使用はローカルの導入問題です。 それはヒントとして音声メールの言語に関して受取人(例えば、エンドユーザか自動化された翻訳の過程)に使用されるかもしれません。
4.4. Voice Message Content Types
4.4. 音声メール内容タイプ
The content types described in this section are identified for use within the Multipart/Voice-Message content. This content is referred to as a "VPIM message" in this document and is the fundamental part of a "VPIM message".
このセクションで説明された満足しているタイプは声Multipart/メッセージ内容の中の使用のために特定されます。 この内容は、本書では「VPIMメッセージ」と呼ばれて、「VPIMメッセージ」の基本的な部分です。
Vaudreuil & Parsons Standards Track [Page 19] RFC 3801 VPIMv2 June 2004
ボードルイと教区牧師標準化過程[19ページ]RFC3801VPIMv2 June 2004
Only the contents profiled can be sent within a VPIM voice message construct (i.e., the Multipart/Voice-Message content type) to form a simple or a more complex structure (several examples are given in Appendix B). The presence of other contents within a VPIM voice message is not permitted. In the absence of a bilateral agreement, conforming implementations MUST NOT create a message containing prohibited contents. In the spirit of liberal acceptance, a conforming implementation MAY accept and render prohibited content. Systems unable to accept or render prohibited contents MAY discard the prohibited contents as necessary to deliver the acceptable content. When multiple contents are present within the Multipart/Voice-Message, they SHOULD be presented to the user in the order that they appear in the message.
簡単な構造か、より複雑な構造を形成するためにVPIM音声メール構造物(すなわち、声Multipart/メッセージ内容タイプ)の中に輪郭を描かれたコンテンツだけは送ることができます(いくつかの例がAppendix Bで出されます)。 VPIM音声メールの中の他のコンテンツの存在は受入れられません。 二国間条約がないとき、実現を従わせると、禁止されたコンテンツを含むメッセージは作成されてはいけません。 寛容な承認の精神に、従う実現は、禁止された内容を受け入れて、表すかもしれません。 禁止されたコンテンツを受け入れるか、またはレンダリングできないシステムは、許容できる内容を送るために必要に応じて禁止されたコンテンツを捨てるかもしれません。 複数のコンテンツが声Multipart/メッセージの中に存在していて、それらはSHOULDです。いつ、彼らがメッセージで見えるオーダーにおけるユーザに提示されるか。
Some deployed implementations based on a common interpretation of the original VPIM v2 specification reject messages with prohibited content rather than discard the unsupported contents. For interoperability with these systems, it is especially important that prohibited contents not be sent within a Multipart/Voice-Message.
いくつかの配備された実現が捨てるよりむしろサポートされないコンテンツを禁止された内容があるオリジナルのVPIM v2仕様廃棄物メッセージの一般的な解釈に基礎づけました。 これらのシステムがある相互運用性において、禁止されたコンテンツが声Multipart/メッセージの中で送られないのは、特に重要です。
4.4.1. Multipart/Voice-Message
4.4.1. 複合かメッセージを声に出します。
This MIME multipart structure provides a mechanism for packaging a voice message into one container that is tagged as VPIM v2 conforming. The sub-type is identical in semantics and syntax to multipart/mixed, as defined in [MIME2]. As such, it may be safely interpreted as a multipart/mixed by systems that do not understand the sub-type (only the identification as a voice message would be lost).
このMIMEの複合構造はVPIM v2の従うとしてタグ付けをされる1個の容器の中に音声メールをパッケージするのにメカニズムを提供します。 サブタイプは[MIME2]で定義されるように意味論と構文が複合か混ぜられるのと同じです。 そういうものとして、複合/がサブタイプを理解していないシステムで混入したので(音声メールとしての識別だけが失われるでしょう)、それは安全に解釈されるかもしれません。
In addition to the MIME required boundary parameter, a version parameter is also required for this sub-type. This is to distinguish this refinement of the sub-type from the previous definition in [VPIM1]. The value of the version parameter is "2.0" if the content conforms to the requirements of this specification. Should there be further revisions of this content type, there MUST be backwards compatibility (i.e., systems implementing version n can read version 2, and systems implementing version 2 can read version 2 contents within a version n).
また、MIME必要な境界パラメタに加えて、バージョンパラメタがこのサブタイプに必要です。 これは、[VPIM1]との前の定義とサブタイプのこの気品を区別するためのものです。 バージョンパラメタの値は「2インチは内容であるならこの仕様の要件に従います」です。 この満足しているタイプの改正がそうさらにあるべきであり、互換性が後方にあるに違いありません(すなわち、バージョンnを実行するシステムはバージョン2を読み込むことができます、そして、バージョン2を実行するシステムはバージョンnの中でバージョン2にコンテンツを読み込むことができます)。
SEND RULES
規則を送ってください。
The Multipart/Voice-Message content-type MUST only contain the profiled media and content types specified in this section (i.e., Audio/*, Image/*, and Message/RFC822). The most common will be: spoken name, spoken subject, the message itself, and an attached fax. Forwarded messages are created by simply using the Message/RFC822 construct.
声のメッセージ内容Multipart/タイプはこのセクション(すなわち、Audio/*、Image/*、およびMessage/RFC822)で指定された輪郭を描かれたメディアと満足しているタイプを含むだけでよいです。 最も一般的であるのは以下の通りになるでしょう。 話された名前、話された対象、メッセージ自体、および付属ファックス。 転送されたメッセージは、単にMessage/RFC822構造物を使用することによって、作成されます。
Vaudreuil & Parsons Standards Track [Page 20] RFC 3801 VPIMv2 June 2004
ボードルイと教区牧師標準化過程[20ページ]RFC3801VPIMv2 June 2004
Conformant implementations MUST use Multipart/Voice-Message in a VPIM message. In most cases, this Multipart/Voice-Message Content-Type will be the top level but may be included within a Message/RFC822 if the message is forwarded or within a multipart/mixed when more than one message is being forwarded.
Conformant実現はVPIMメッセージの声Multipart/メッセージを使用しなければなりません。 多くの場合、この声Multipart/メッセージコンテントタイプをトップレベルですが、1つ以上のメッセージを転送しているとき、メッセージが転送するか、または複合/の中で複雑であるなら、Message/RFC822の中に含むかもしれません。
RECEIVE RULES
規則を受け取ってください。
Conformant implementations MUST recognize the Multipart/Voice-Message content (whether it is a top-level content or contained in a Multipart/Mixed) and MUST be able to separate the contents (e.g., spoken name or spoken subject).
Conformant実現は、声Multipart/メッセージ内容を認識しなければならなくて(それが満足しているかMultipart/Mixedに含まれたトップレベルであるか否かに関係なく)、コンテンツを切り離すことができなければなりません(例えば、名前を話すか、または対象を話します)。
The semantic of Multipart/Voice-Message (defined in section 18.2) is identical to Multipart/Mixed and may be interpreted as that by systems that do not recognize this content-type.
声Multipart/メッセージ(セクション18.2で、定義される)の意味は、Multipart/Mixedと同じであり、この満足しているタイプを見分けないシステムによるそれとして解釈されるかもしれません。
4.4.2. Message/RFC822
4.4.2. メッセージ/RFC822
SEND RULES
規則を送ってください。
MIME requires support of the Message/RFC822 message encapsulation body part. This body part SHOULD be used within a Multipart/Voice- Message to forward complete messages (see 4.8) or to reply with original content (see 4.9). From: [MIME2]
MIMEはMessage/RFC822メッセージカプセル化身体の部分のサポートを必要とします。 このボディーはSHOULDを分けます。完全なメッセージ(4.8を見る)を転送するか、またはオリジナルコンテンツで返答するMultipart/声のメッセージの中で使用されてください(4.9を見てください)。 From: [MIME2]
RECEIVE RULES
規則を受け取ってください。
The receiving system MUST accept this format and SHOULD treat this attachment as a forwarded message. The receiving system MAY flatten the forwarding structure (i.e., remove this construct to leave multiple voice contents or even concatenate the voice contents to fit in a recipient's mailbox), if necessary.
受電方式はこの形式を受け入れなければなりません、そして、SHOULDは転送されたメッセージとしてこの付属を扱います。 必要なら、受電方式は推進構造(すなわち、複数の声をコンテンツに残すか、または受信者のメールボックスの中で合う声のコンテンツを連結するのさえこの構造物を取り除く)を平らにするかもしれません。
4.4.3. Audio/32KADPCM
4.4.3. オーディオ/32KADPCM
SEND RULES
規則を送ってください。
An implementation conforming to this profile MUST send Audio/32KADPCM by default for voice [ADPCM]. This encoding is a moderately- compressed encoding with a data rate of 32 kbits/second using moderate processing resources. Typically, this body contains several minutes of message content; however, if used for spoken name or subject the content is expected to be considerably shorter (i.e., about 5 and 10 seconds respectively).
このプロフィールに従う実現は声[ADPCM]のためにデフォルトでAudio/32KADPCMを送らなければなりません。 このコード化は32kbits/秒のデータ信号速度が適度の処理リソースを使用している適度に圧縮されたコード化です。 通常、このボディーは数分のメッセージ内容を含みます。 しかしながら、話された名前か対象に使用されるなら内容がかなり短いと予想される、(すなわち、およそ5と10がそれぞれ後援する、)
Vaudreuil & Parsons Standards Track [Page 21] RFC 3801 VPIMv2 June 2004
ボードルイと教区牧師標準化過程[21ページ]RFC3801VPIMv2 June 2004
RECEIVE RULES
規則を受け取ってください。
Receivers MUST be able to accept and decode Audio/32KADPCM. If an implementation can only handle one voice body, then multiple voice bodies (if present) SHOULD be concatenated, and MUST NOT be discarded. If concatenated, the contents SHOULD be in the same order they appeared in the multipart.
受信機は、Audio/32KADPCMを受け入れて、解読できなければなりません。 実現が1つの声の本体しか扱うことができないなら、複数の声の本体(存在しているなら)SHOULDを連結して、捨ててはいけません。 連結されるなら、コンテンツSHOULDは彼らが複合で見えた同次で連結されます。
4.4.4. Image/TIFF
4.4.4. イメージ/いさかい
A common image encoding for facsimile, known as TIFF-F, is a derivative of the Tag Image File Format (TIFF) and is described in several documents. For the purposes of VPIM, the F Profile of TIFF for Facsimile (TIFF-F) is defined in [TIFF-F], and the Image/TIFF MIME content-type is defined in [TIFFREG]. While there are several formats of TIFF, only TIFF-F is profiled for use within Multipart/Voice-Message. Further, since the TIFF-F file format is used in a store-and-forward mode with VPIM, the image MUST be encoded so that there is only one image strip per facsimile page.
TIFF-Fとして知られているファクシミリのためにコード化される一般的なイメージは、Tag Image File Format(TIFF)の派生物であり、いくつかのドキュメントで説明されます。 VPIMの目的のために、Facsimile(TIFF-F)のためのTIFFのF Profileは[TIFF-F]で定義されます、そして、Image/TIFFのMIMEの満足しているタイプは[TIFFREG]で定義されます。 TIFFのいくつかの形式がある間、TIFF-Fだけが声Multipart/メッセージの中の使用のために輪郭を描かれます。 TIFF-Fファイル形式がVPIMと共に店とフォワードモードで使用されるのでさらに、イメージをコード化しなければならないので、ファクシミリページあたり1イメージ片しかありません。
SEND RULES
規則を送ってください。
All VPIM implementations that support facsimile MUST generate TIFF-F compatible facsimile contents in the Image/TIFF subtype using the application=faxbw encoding by default. If the VPIM message is a voice- annotated fax, the implementation SHOULD send this fax content in Multipart/Voice-Message. If the message is a simple fax, an implementation MAY send it without using the Multipart/Voice-Message to be more compatible with fax-only (RFC 2305) implementations.
デフォルトでfaxbwアプリケーション=コード化を使用して、ファクシミリを支持するすべてのVPIM実現がImage/TIFF subtypeでTIFF-Fコンパチブルファクシミリコンテンツを発生させなければなりません。 VPIMメッセージが音声の注釈されたファックスであるなら、実現SHOULDは声Multipart/メッセージのこのファックス内容を送ります。 メッセージが簡単なファックスであるなら、ファックス(RFC2305)だけ実現と、より互換性がある声Multipart/メッセージを使用しないで、実現はそれを送るかもしれません。
While any valid MIME body header MAY be used (e.g., Content- Disposition to indicate the filename), none are specified to have special semantics for VPIM and MAY be ignored. Note that the content-type parameter application=faxbw MUST be included in outbound messages.
どんな有効なMIMEボディーヘッダーも使用されているかもしれない間(例えば、ファイル名を示すContent気質)、なにも、VPIMに、特別な意味論を持つために指定されて、無視されないかもしれません。 外国行きのメッセージに満足している型引数アプリケーション=faxbwを含まなければならないことに注意してください。
RECEIVE RULES
規則を受け取ってください。
Not all VPIM systems support fax, but all SHOULD accept it within the multipart/voice-message. Within a Multipart/Voice-Message, a receiving system that cannot render fax content SHOULD accept the voice content of a VPIM message and discard the fax content. Outside a Multipart/Voice-Message, a recipient system MAY reject (with appropriate NDN) the entire message if it cannot store or is not capable of rendering a message with fax attachments. VPIM conforming systems MAY support fax outside of (or without) the Multipart/Voice- Message.
VPIMシステムサポートがファックスで送るすべてではなく、すべてのSHOULDが複合/音声メールの中でそれを受け入れます。 声Multipart/メッセージ、ファックス内容を表すことができない受電方式の中では、SHOULDはVPIMメッセージの声の内容を受け入れて、ファックス内容を捨てます。 声Multipart/メッセージの外では、それが保存できませんし、できもしないなら、受取人システムはファックス付属をもって公式に伝言を伝えるのについて全体のメッセージを拒絶するかもしれません(適切なNDNと共に)。 システム5月のサポートを従わせるVPIMが(or without)の外でファックスでMultipart/声のメッセージを送ります。
Vaudreuil & Parsons Standards Track [Page 22] RFC 3801 VPIMv2 June 2004
ボードルイと教区牧師標準化過程[22ページ]RFC3801VPIMv2 June 2004
Some deployed implementations based on a common interpretation of the original VPIM V2 specification reject messages with fax content within the Multipart/Voice-Message rather than discard the unsupported contents. These systems will return the message to the sender with an NDN indicating lack of support for fax.
声Multipart/メッセージの中にファックス内容がある状態で、当初のVPIM V2仕様の一般的な解釈に基づく実装であると配布された或るものはサポートされないコンテンツを捨てるよりむしろメッセージを拒絶します。 これらのシステムはNDNがファックスのサポートの不足を示している送付者にメッセージを返すでしょう。
4.5. Other MIME Contents
4.5. 他のMIMEコンテンツ
The following MIME contents (with the exception of multipart/mixed in section 4.5.1) MAY be included within a multipart/voice message. Other contents MUST NOT be included. Their handling is a local implementation issue. Multipart/mixed is included to promote interoperability with a wider range of systems and also to allow the creation of more complex multimedia messages (with a VPIM message as one part).
以下のMIMEコンテンツ(複合かセクション4.5.1で混ぜられるのを除いた)は複合/音声メールの中に含まれるかもしれません。 他のコンテンツを含んではいけません。 彼らの取り扱いはローカルの導入問題です。 混ぜられた複合/は、より広い範囲のシステムで相互運用性を促進して、また、より複雑なマルチメディアメッセージ(一部としてのVPIMメッセージがある)の作成を許容するために含まれています。
4.5.1. Multipart/Mixed
4.5.1. 複合か混ぜられます。
This common MIME content-type allows the enclosing of several body parts in a single message.
この一般的なMIME content typeはただ一つのメッセージにおける、いくつかの身体の部分の同封を許します。
SEND RULES
規則を送ってください。
A VPIM voice message (i.e., multipart/voice-message) MAY be included within a message with a Multipart/Mixed top-level content type. Typically, this would only be used when mixing non-voice and non-fax contents with a voice message.
VPIM音声メール(すなわち、複合/音声メール)はメッセージの中にMultipart/Mixedトップレベルcontent typeで含まれるかもしれません。 非声の、そして、非ファックスのコンテンツを音声メールに混ぜるときだけ、通常、これは使用されるでしょう。
RECEIVE RULES
規則を受け取ってください。
Such a message is not itself a VPIM message and the handling of such a construct is outside the scope of the VPIM profile. However, an the spirit of liberal acceptance, a conforming implementation MUST accept and render a VPIM voice message contained in a Multipart/Mixed.
そのようなメッセージはそれ自体でVPIMメッセージではありません、そして、VPIMプロフィールの範囲の外にそのような構造物の取り扱いがあります。 しかしながら、寛容な承認の精神、従う実装はMultipart/MixedにVPIM音声メールを含むように受け入れて、レンダリングしなければなりません。
4.5.2. Text/Directory
4.5.2. テキスト/ディレクトリ
SEND RULES
規則を送ってください。
This content was profiled in the original specification of VPIM v2 as a means of transporting contact information from the sender to the recipient. This usage did not find widespread adoption and is no longer a feature of VPIM V2. Conforming implementations SHOULD NOT send the Text/Directory content type.
この内容は送付者から受取人まで問い合わせ先を輸送する機関としてVPIM v2に関する正式仕様書で輪郭を描かれました。 この用法は、広範囲の採用を見つけないで、またもうVPIM V2の特徴ではありません。 従っている実装SHOULD NOTはText/ディレクトリcontent typeを送ります。
Vaudreuil & Parsons Standards Track [Page 23] RFC 3801 VPIMv2 June 2004
ボードルイと教区牧師標準化過程[23ページ]RFC3801VPIMv2 June 2004
RECEIVE RULES
規則を受け取ってください。
For compatibility with an earlier specification of VPIM v2, the Text/Directory content type MUST be accepted by a conforming implementation, but need not be stored, processed, or rendered to the recipient.
VPIM v2の以前の仕様との互換性において、従う実装でText/ディレクトリcontent typeを受け入れなければなりません、保存する必要はないか、処理する必要はないか、または受取人に提供する必要はありませんが。
4.5.3. Proprietary Voice or Fax Formats
4.5.3. 独占声かファックス形式
Use of any other encoding except the required codecs reduces interoperability in the absence of explicit knowledge about the capabilities of the recipient. A conforming implementation SHOULD NOT use any other encoding unless a unique identifier is registered with the IANA prior to use (see [MIME4]). The voice encodings SHOULD be registered as subtypes of Audio. The fax encodings SHOULD be registered as subtypes of Image.
必要なコーデックを除いたいかなる他のコード化の使用も受取人の能力に関する形式知がないとき相互運用性を減少させます。 ユニークな識別子が使用の前のIANAに登録されない場合([MIME4]を見てください)、従う実装SHOULD NOTはいかなる他のコード化も使用します。 登録されていて、Audioの血液型亜型としてencodings SHOULDを声に出してください。 登録されていて、Imageの血液型亜型としてencodings SHOULDにファックスしてください。
SEND RULES
規則を送ってください。
Proprietary voice encoding formats or other standard formats SHOULD NOT be sent under this profile unless the sender has a reasonable expectation that the recipient will accept the encoding. In practice, this requires explicit per-destination configuration information maintained either in a directory, personal address book, or gateway configuration tables.
送られた下がこのプロフィールであり、送付者が受取人が持っている合理的な期待を持っていない場合形式か他の標準書式SHOULD NOTをコード化する独占声がコード化を受け入れます。 実際には、これはディレクトリ、個人的なアドレス帳、またはゲートウェイ構成テーブルで維持された1目的地あたりの明白な設定情報を必要とします。
RECEIVE RULES
規則を受け取ってください。
Systems MAY accept other Audio/* or Image/* content types if they can decode them. Systems which receive Audio/* or Image/* content types which they are unable to deposit or unable to render MUST return the message (and SHOULD include the original content) to the originator with an NDN indicating media not supported.
それらを解読できるなら、システムは他のAudio/*かImage/*content typeを受け入れるかもしれません。 それらが預けることができませんし、またレンダリングできないAudio/*かImage/*content typeを受けるシステムはメッセージ(SHOULDはオリジナルコンテンツを含んでいる)をメディアがサポートしなかったのを示すNDNの創始者に返さなければなりません。
4.5.4. Text/Plain
4.5.4. テキスト/平野
MIME requires support of the basic Text/Plain content type (with the US-ASCII character set). This content type has limited applicability within the voice-messaging environment. However, because VPIM is a MIME profile, MIME requirements SHOULD be met.
MIMEは基本的なText/明瞭なcontent type(米国-ASCII文字の組がある)のサポートを必要とします。 このcontent typeは声を通信させる環境の中で適用性を制限しました。 MIME要件SHOULD、VPIMはMIMEプロフィールです。しかしながら、会われます。
SEND RULES
規則を送ってください。
Conforming VPIM implementations SHOULD NOT send the Text/Plain content-type. Implementations MAY send the Text/Plain content-type outside the Multipart/Voice-Message.
従っているVPIM実装SHOULD NOTはText/明瞭なcontent typeを送ります。 実装は声Multipart/メッセージの外にText/明瞭なcontent typeを送るかもしれません。
Vaudreuil & Parsons Standards Track [Page 24] RFC 3801 VPIMv2 June 2004
ボードルイと教区牧師標準化過程[24ページ]RFC3801VPIMv2 June 2004
RECEIVE RULES
規則を受け取ってください。
Within a Multipart/Voice-Message, the Text/Plain content-type MAY be dropped from the message, if necessary, to deliver the audio/fax components. The recipient SHOULD NOT reject the entire message if the text component cannot be accepted or rendered.
必要なら、声Multipart/メッセージの中では、Text/明瞭なcontent typeは、オーディオ/ファックスの部品を提供するためにメッセージから下げられるかもしれません。 テキストコンポーネントを受け入れることができませんし、レンダリングできないなら、受取人SHOULD NOTは全体のメッセージを拒絶します。
Outside a Multipart/Voice-Message, conforming implementations MUST accept Text/Plain; however, specific handling is left as an implementation decision. From: [MIME2]
声Multipart/メッセージの外では、実装を従わせると、Text/平野は受け入れられなければなりません。 しかしながら、特定の取り扱いは実装決定として残されます。 From: [MIME2]
Some deployed implementations based on a common interpretation of the original VPIM V2 specification reject messages with any text content rather than discard the unsupported contents. These systems will return the message to the sender with an NDN indicating lack of support for text.
実装であると配布された或るものは捨てるよりむしろサポートされないコンテンツをどんなテキスト内容があるオリジナルのVPIM V2仕様廃棄物メッセージの一般的な解釈にも基礎づけました。 これらのシステムはNDNがテキストのサポートの不足を示している送付者にメッセージを返すでしょう。
4.6. Delivery Status Notification (DSN)
4.6. 配送状態通知(DSN)
A DSN is a notification of delivery (positive DSN), non-delivery (negative DSN), or temporary delivery delay (delayed DSN). The top- level content-type of a DSN is Multipart/Report, which is defined in [REPORT]. The content-type which distinguishes DSN's from other types of notifications is Message/Delivery-Status, which is defined in [DSN].
DSNは配送(積極的なDSN)、非配送(否定的DSN)、または一時的な配送遅れ(DSNを遅らせる)が通知です。 DSNの先端の平らなcontent typeはMultipart/レポートです。(そのレポートは[REPORT]で定義されます)。 他のタイプに関する通知とDSNのものを区別するcontent typeは配送Message/状態です。(その状態は[DSN]で定義されます)。
SEND RULES
規則を送ってください。
A VPIM-compliant implementation MUST be able to send DSN's that conform to [REPORT] and [DSN]. Unless requested otherwise, a non- delivery DSN MUST be sent when any form of non-delivery of a message occurs.
VPIM対応することの実装は[REPORT]と[DSN]に従うDSNのものを送ることができなければなりません。 どんな形式のメッセージの非配送も起こるとき、そうでなければ非配送しているDSN MUSTが送られるよう要求しました。
A VPIM-compliant implementation SHOULD provide a spoken delivery status in the "human-readable" body part of the DSN, but MAY provide a textual status.
DSNの「人間読み込み可能な」身体の部分に話された配送状態を提供しますが、SHOULDが原文の状態を提供するかもしれないVPIM対応することの実装。
RECEIVE RULES
規則を受け取ってください。
A VPIM-compliant implementation MUST be able to receive DSN's that conform to [REPORT] and [DSN].
VPIM対応することの実装は[REPORT]と[DSN]に従うDSNのものを受け取ることができなければなりません。
A VPIM-compliant implementation MUST be able to receive a DSN whose "human-readable" body part contains a spoken delivery status phrase or a textual description. Though subsequent use of the phrase or text is a local implementation issue, the intent of the DSN MUST be presented to the end user.
VPIM対応することの実装は「人間読み込み可能な」身体の部分が話された配送状態句か原文の記述を含むDSNを受け取ることができなければなりません。 その後ですが、句かテキストの使用はローカルの導入問題です、DSN MUSTの意図。エンドユーザに提示されます。
Vaudreuil & Parsons Standards Track [Page 25] RFC 3801 VPIMv2 June 2004
ボードルイと教区牧師標準化過程[25ページ]RFC3801VPIMv2 June 2004
4.7. Message Disposition Notification (MDN)
4.7. メッセージ気質通知(MDN)
An MDN is a notification indicating what happens to a message after it is deposited in the recipient's mailbox. An MDN can be positive (message was read/played/rendered/etc.) or negative (message was deleted before recipient could see it, etc.). The top-level content-type of a MDN is Multipart/Report, which is defined in [REPORT]. The content-type which distinguishes MDN's from other types of notifications is Message/Disposition-Notification, which is defined in [MDN].
MDNはそれが受信者のメールボックスに預けられた後にメッセージがどうなるかを示す通知です。 MDNは肯定しているか(/などがプレーされるか、またはレンダリングされて、/はメッセージに読み込まれました)、または否定している場合があります(受取人がそれなどを見ることができる前にメッセージは削除されました)。 MDNのトップレベルcontent typeはMultipart/レポートです。(そのレポートは[REPORT]で定義されます)。 他のタイプに関する通知とMDNのものを区別するcontent typeは気質Message/通知です。(その通知は[MDN]で定義されます)。
SEND RULES
規則を送ってください。
A VPIM-compliant implementation SHOULD support the ability to request MDNs. This is done via the use of the "Disposition-Notification-To:" header field as defined in [MDN].
SHOULDがMDNsを要求する能力をサポートするVPIM対応することの実装。 「気質通知To:」の使用でこれをします。 [MDN]で定義されるヘッダーフィールド。
A VPIM-compliant implementation SHOULD support the ability to send MDNs, but these MDNs MUST conform to [REPORT] and [MDN].
SHOULDがMDNs、しかし、これらのMDNsを送る能力をサポートするVPIM対応することの実装は[REPORT]と[MDN]に従わなければなりません。
When sending an MDN, a VPIM-compliant implementation SHOULD provide a spoken message disposition in the "human-readable" body part of the MDN, but MAY provide a textual status.
MDNを送るとき、MDNの「人間読み込み可能な」身体の部分に口頭の伝言気質を提供しますが、SHOULDが原文の状態を提供するかもしれないVPIM対応することの実装です。
RECEIVE RULES
規則を受け取ってください。
A VPIM-compliant implementation SHOULD respond to an MDN request with an MDN response.
SHOULDがMDN応答でMDN要求に反応させるVPIM対応することの実装。
A VPIM-compliant implementation MUST be able to receive MDNs that conform to [REPORT] and [MDN], if it is capable of requesting MDNs. If a VPIM-compliant implementation is capable of receiving MDNs, it MUST be able to receive a MDN whose "human-readable" body part contains a spoken message disposition phrase or a textual disposition description. Though subsequent use of the phrase or text is a local implementation issue, the intent of the MDN MUST be presented to the end user.
VPIM対応することの実装は[REPORT]と[MDN]に従うMDNsを受け取ることができなければなりません、MDNsを要求できるなら。 VPIM対応することの実装がMDNsを受けることができるなら、「人間読み込み可能な」身体の部分が口頭の伝言気質句か原文の気質記述を含むMDNを受け取ることができなければなりません。 その後ですが、句かテキストの使用はローカルの導入問題です、MDN MUSTの意図。エンドユーザに提示されます。
4.8. Forwarded Messages
4.8. 転送されたメッセージ
VPIM v2 explicitly supports the forwarding of voice and fax content with voice or fax annotation. However, only the two constructs described below are acceptable in a VPIM message. Since only the first (i.e., Message/RFC822) can be recognized as a forwarded message (or even multiple forwarded messages), it is RECOMMENDED that this construct be used whenever possible.
VPIM v2は明らかに声かファックス注釈による声とファックス内容の推進をサポートします。 しかしながら、以下で説明された2個の構造物だけがVPIMメッセージで許容できます。 1番目しか認識できないので(すなわち、Message/RFC822)、転送されたメッセージ(または、複数の転送されたメッセージさえ)として、可能であるときはいつも、この構造物が使用されるのは、RECOMMENDEDです。
Vaudreuil & Parsons Standards Track [Page 26] RFC 3801 VPIMv2 June 2004
ボードルイと教区牧師標準化過程[26ページ]RFC3801VPIMv2 June 2004
Forwarded VPIM messages SHOULD be sent as a Multipart/Voice-Message with the entire original message enclosed in a Message/RFC822 content-type and the annotation as a separate Audio/* or Image/* body part. If the RFC822 header fields are not available for the forwarded content, simulated header fields with available information SHOULD be constructed to indicate the original sending timestamp, and the original sender as indicated in the "From:" field. Note that at least one of "From:", "Subject:", or "Date:" MUST be present. As well, the Message/RFC822 content MUST include at least the "MIME- Version:", and "Content-Type:" header fields. From: [MIME2]
VPIMメッセージSHOULDを進めて、全体のオリジナルのメッセージがMessage/RFC822content typeで同封されている声Multipart/メッセージと別々のAudio/*かImage/*ボディーとしての注釈が離れているので、送ってください。 RFC822ヘッダーフィールドが転送された内容、入手可能な情報SHOULDがオリジナルの送付タイムスタンプを示すために組み立てられているシミュレートされたヘッダーフィールド、および「From:」にみられるように元の送り主に利用可能でないなら さばきます。 「From:」、「Subject:」、または「日付:」についてそんなに少なくとも1つに注意してください。 存在しなければならなくなってください。 そして、また、Message/RFC822内容が含まなければならない、少なくとも、「バージョンをまねてください」、「コンテントタイプ:」 ヘッダーフィールド。 From: [MIME2]
In the event that forwarding information is lost, the entire audio content MAY be sent as a single Audio/* segment without including any forwarding semantics. An example of this loss is an AMIS message being forwarded through an AMIS-to-VPIM gateway.
推進情報が無くなる場合、どんな推進意味論も含んでいなくて、ただ一つのAudio/*セグメントとして全体のオーディオ内容を送るかもしれません。 この損失に関する例はエイミスからVPIMへのゲートウェイを通して転送されるエイミスメッセージです。
4.9. Reply Messages
4.9. 応答メッセージ
VPIM v2 explicitly supports replying to received messages.
VPIM v2は明らかに受信されたメッセージに関する返答をサポートします。
Support of multiple originator header fields in a reply message is often not possible on voice messaging systems, so it may be necessary to choose only one when gatewaying a VPIM message to another voice message system. However, implementers should note that this may make it impossible to send DSN's, MDN's, and replies to their proper destinations.
応答メッセージにおける、複数の創始者ヘッダーフィールドのサポートが声のメッセージシステムでしばしば可能であるというわけではないので、別の音声メールシステムにVPIMメッセージをgatewayingするとき、1つだけを選ぶのが必要であるかもしれません。 しかしながら、implementersは、これでDSN、MDN、および回答をそれらの適切な目的地に送るのが不可能になるかもしれないことに注意するはずです。
In some cases, replying to a message is not possible, such as with a message created by telephone answering (i.e., classic voice mail). In this case, the From field SHOULD contain the special address non- mail-user@domain (see 4.1.2). The recipient's VPIM system SHOULD NOT offer the option to reply to this kind of message (unless an outcalling feature is offered - which is out of scope for VPIM).
いくつかの場合、メッセージに答えるのは可能ではありません、(すなわち、古典的なボイスメール)に答える電話によって作成されるメッセージなどのように。 この場合From分野SHOULDが特別なアドレス非 mail-user@domain を含む、(見る、4.1、.2、) 受取人のVPIMシステムSHOULD NOTは、この種類に関するメッセージに答えるためにオプションを提供します(「外-呼」ぶことの特徴が提供されない場合(VPIMのための範囲の外にあります))。
5. Message Transport Protocol
5. メッセージ転送プロトコル
Messages are transported between voice mail machines using the Internet Extended Simple Mail Transfer Protocol (ESMTP). All information required for proper delivery of the message is included in the ESMTP dialog. This information, including the sender and recipient addresses, is commonly referred to as the message "envelope". This information is equivalent to the message control block in many analog voice messaging protocols.
メッセージは、ボイスメールマシンの間でインターネットExtendedシンプルメールトランスファプロトコル(ESMTP)を使用することで輸送されます。 メッセージの適切な配送に必要であるすべての情報がESMTP対話に含まれています。 送付者と受取人アドレスを含むこの情報が一般的に「封筒」というメッセージと呼ばれます。 この情報は多くのアナログの声のメッセージング・プロトコルでのメッセージ制御ブロックに同等です。
ESMTP is a general-purpose messaging protocol, designed both to send mail and to allow terminal console messaging. Simple Mail Transport Protocol (SMTP) was originally created for the exchange of US-ASCII 7-bit text messages. Binary and 8-bit text messages have
ESMTPはともにメールを送って、端末のコンソールメッセージングを許容するように設計された汎用メッセージング・プロトコルです。 簡単なメールTransportプロトコル(SMTP)は元々、米国-ASCIIの7ビットのテキスト・メッセージの交換のために作成されました。 メッセージにはある2進の、そして、8ビットのテキスト
Vaudreuil & Parsons Standards Track [Page 27] RFC 3801 VPIMv2 June 2004
ボードルイと教区牧師標準化過程[27ページ]RFC3801VPIMv2 June 2004
traditionally been transported by encoding the messages into a 7-bit text-like form. [ESMTP] formalized an extension mechanism for SMTP, and subsequent RFCs have defined 8-bit text networking, command streaming, binary networking, and extensions to permit the declaration of message size for the efficient transmission of large messages such as multi-minute voice mail.
7ビットのテキストのようなフォームにメッセージをコード化することによって、伝統的に輸送されます。 [ESMTP]はSMTPのために拡張機能を正式にしました、そして、その後のRFCsはマルチ分ボイスメールなどの大きいメッセージの効率的な伝達のためにメッセージサイズの宣言を可能にするために8ビットのテキストネットワーク、コマンドストリーミング、2進のネットワーク、および拡大を定義しました。
The following sections list ESMTP commands, keywords, and parameters that are required and those that are optional for conformance to this profile.
以下のセクションはESMTPコマンド、キーワード、必要であるパラメタ、および順応に、このプロフィールに任意のものをリストアップします。
5.1. Base SMTP Protocol
5.1. 基地のSMTPプロトコル
A conforming system MUST implement all mandatory SMTP and ESMTP commands. Any defined optional command or parameter MAY be supported.
従うシステムは、すべての義務的なSMTPとESMTPがコマンドであると実装しなければなりません。 どんな定義された任意のコマンドやパラメタもサポートされるかもしれません。
5.2. SMTP Service Extensions
5.2. SMTPサービス拡張子
VPIM utilizes a number of SMTP Service Extensions to provide full- featured voice messaging service. The following extensions are profiled for use with VPIM:
VPIMは、完全な特集された声のメッセージングサービスを提供するのに多くのSMTP Service Extensionsを利用します。 以下の拡大はVPIMとの使用のために輪郭を描かれます:
5.2.1. DSN Extension
5.2.1. DSN拡張子
The DSN extension defines a mechanism which allows an SMTP client to specify (a) DSN's should be generated under certain conditions, (b) whether such DSN's should return the contents of the message, and (c) additional information, to be returned with a DSN, that allows the sender to identify both the recipient(s) for which the DSN was issued, and the transaction in which the original message was sent.
DSN拡張子は(b) DSNのそのようなものがDSNと共に返すためにメッセージ、および(c)のコンテンツに追加情報を返すはずであるか否かに関係なく、SMTPクライアントがDSNによって一定の条件の下で生成されるはずであった(a)を指定するのを許容して、送付者がDSNが発行された受取人とオリジナルのメッセージが送られたトランザクションの両方を特定するのを許容するメカニズムを定義します。
The DSN extension MUST be supported by VPIM conforming implementations.
実装を従わせるVPIMはDSN拡張子をサポートしなければなりません。
In addition, beyond the requirements of [DRPT], conforming implementations MUST support NOTIFY parameter on the RCPT command to allow indication of when the originator requests a notification. The RET parameter SHOULD be supported to return the original message with the notification. Parameters ORCPT and ENVID MAY also be supported. From: [DRPT]
[DRPT]の要件を超えて実装をさらに、従わせるのは、NOTIFYが創始者が通知を要求する時のしるしを許容するRCPTコマンドに関するパラメタであるとサポートしなければなりません。 RETパラメタSHOULD、サポートされて、通知と共にオリジナルのメッセージを返してください。 パラメタのORCPTとENVID MAY、もサポートされてください。 From: [DRPT]
5.2.2. SIZE Extension
5.2.2. サイズ拡大
The SIZE extension defines a mechanism whereby an SMTP client and server may interact to give the server an opportunity to decline to accept a message (perhaps temporarily) based on the client's estimate of the message size. From: [SIZE]
SIZE拡張子はSMTPクライアントとサーバがクライアントのメッセージサイズの見積りに基づくメッセージ(恐らく一時)を受け入れるのを断る機会をサーバに与えるために相互作用するかもしれないメカニズムを定義します。 From: [サイズ]
Vaudreuil & Parsons Standards Track [Page 28] RFC 3801 VPIMv2 June 2004
ボードルイと教区牧師標準化過程[28ページ]RFC3801VPIMv2 June 2004
The SIZE extension MUST be supported by VPIM-compliant implementations.
VPIM対応することの実装でSIZE拡張子をサポートしなければなりません。
5.2.3. ENHANCEDSTATUSCODES Extension
5.2.3. ENHANCEDSTATUSCODES拡張子
The ENHANCEDSTATUSCODES extension defines a mechanism whereby an SMTP server augments its responses with the enhanced mail system status codes defined in [CODES]. These codes can then be used to provide more informative explanations of error conditions. From: [STATUS]
ENHANCEDSTATUSCODES拡張子は高められたメールシステムステータスコードが[CODES]で定義されている状態でSMTPサーバーが応答を増大させるメカニズムを定義します。 そして、エラー条件の、より有益な説明を提供するのにこれらのコードを使用できます。 From: [状態]
The ENHANCEDSTATUSCODES extension SHOULD be supported by VPIM- compliant implementations.
ENHANCEDSTATUSCODES拡張子SHOULD、VPIM対応することの実装で、サポートされてください。
5.2.4. PIPELINING Extension
5.2.4. パイプライン処理拡大
The PIPELINING extension defines a mechanism whereby an SMTP server can indicate the extent of its ability to accept multiple commands in a single TCP send operation. Using a single TCP send operation for multiple commands can improve SMTP performance significantly. From [PIPE]
PIPELINING拡張子はTCPが操作を送るシングルでSMTPサーバーが複数のコマンドを受け入れる性能の範囲を示すことができるメカニズムを定義します。 複数のコマンドにTCPが操作を送るシングルを使用するのはSMTP性能をかなり向上させることができます。 from[パイプ]
The PIPELINING extension SHOULD be supported by VPIM-compliant implementations.
PIPELINING拡張子SHOULD、VPIM対応することの実装で、サポートされてください。
5.2.5. CHUNKING Extension
5.2.5. 分魂化拡大
The CHUNKING extension defines a mechanism that enables an SMTP client and server to negotiate the use of the message data transfer command "BDAT" (in alternative to the DATA command) for efficiently sending large MIME messages. From: [BINARY]
CHUNKING拡張子はSMTPクライアントとサーバがメッセージデータ転送コマンド"BDAT"(データコマンドへの代替手段による)の効率的に大きいMIMEメッセージを送る使用を交渉するのを可能にするメカニズムを定義します。 From: [2進]です。
The CHUNKING extension MAY be supported by VPIM-compliant implementations.
CHUNKING拡張子はVPIM対応することの実装によってサポートされるかもしれません。
5.2.6. BINARYMIME Extension
5.2.6. BINARYMIME拡張子
The BINARYMIME extension defines a mechanism that enables an SMTP client and server to negotiate the transfer of unencoded binary message data utilizing the BDAT command. From: [BINARY]
BINARYMIME拡張子はSMTPクライアントとサーバがBDATコマンドを利用する暗号化されていない2進のメッセージデータの転送を交渉するのを可能にするメカニズムを定義します。 From: [2進]です。
The BINARYMIME extension MAY be supported by VPIM-compliant implementations. Note that [BINARY] specifies that if BINARYMIME is to be supported, then CHUNKING has to be supported by definition.
BINARYMIME拡張子はVPIM対応することの実装によってサポートされるかもしれません。 [BINARY]が、BINARYMIMEがサポートされるつもりであるならCHUNKINGが定義上サポートされなければならないと指定することに注意してください。
Vaudreuil & Parsons Standards Track [Page 29] RFC 3801 VPIMv2 June 2004
ボードルイと教区牧師標準化過程[29ページ]RFC3801VPIMv2 June 2004
5.3. ESMTP - SMTP Downgrading
5.3. ESMTP--SMTP格下げ
The SMTP extensions suggested or required for conformance to VPIM fall into two categories. The first category includes features that increase the efficiency of the transport system such as SIZE, BINARYMIME, and PIPELINING. In the event of a downgrade to a less- functional transport system, these features can be dropped with no functional change to the sender or recipient.
順応にVPIMに示されるか、または必要であるSMTP拡張子は2つのカテゴリになります。 最初のカテゴリはSIZEや、BINARYMIMEや、PIPELININGなどの輸送システムの効率を増強する特徴を含んでいます。 ダウングレードの場合、機能的な変化なしで、より少ない機能的な輸送システム、aへのこれらの特徴を送付者か受取人に下げることができます。
The second category of features is transport extensions in support of new functions. DSN and ENHANCEDSTATUSCODES provide essential improvements in the handling of delivery status notifications to bring email to the level of reliability expected of Voice Mail. To ensure a consistent level of service across an intranet or the global Internet, it is essential that VPIM-conforming ESMTP support the DSN extension at all hops between a VPIM originating system and the recipient system. In the situation where a "downgrade" is unavoidable a relay hop may be forced (by the next hop) to forward a VPIM message without the ESMTP request for delivery status notification. It is RECOMMENDED that the downgrading system should continue to attempt to deliver the message, but MUST send an appropriate delivery status notification to the originator, e.g., the message left an ESMTP host and was sent relayed to a non-DSN-aware destination, and this may be the last DSN received.
特徴の2番目のカテゴリは新しい機能を支持した輸送拡大です。 DSNとENHANCEDSTATUSCODESは、Voiceメールに予想された信頼性のレベルにメールをもたらすために配送状態通知の取り扱いにおける不可欠の改良を提供します。 イントラネットか世界的なインターネットの向こう側に一貫したレベルのサービスを確実にするために、VPIM-従うESMTPがVPIM起因するシステムと受取人システムの間のホップを全くDSN拡張子にサポートするのは、不可欠です。 「ダウングレード」が避けられない状況で、リレーホップは配送状態通知に関するESMTP要求なしでやむを得ずVPIMメッセージを転送するかもしれません(次のホップで)。 目的地、およびこれはそうです。aにリレーされて、格下げシステムがメッセージを提供するのを試み続けるべきですが、適切な配送状態通知を創始者に送らなければならなくて、例えば、メッセージをESMTPホストを置き去りにして、送ったのが、RECOMMENDEDである、非DSN意識する、受け取られた最後のDSN。
6. Directory Address Resolution
6. ディレクトリアドレス解決
It is the responsibility of a VPIM system to provide the fully- qualified domain name (FQDN) of the recipient based on the address entered by the user (if the entered address is not already a FQDN). This would typically be an issue on systems that offer only a telephone user interface. The mapping of the dialed target number to a routable FQDN address, allowing delivery to the destination system, can be accomplished through implementation-specific means.
ユーザによって入れられたアドレスに基づく受取人の完全に適切なドメイン名(FQDN)を提供するのは、VPIMシステムの責任(入力されたアドレスが既にFQDNでないなら)です。 これは通常、電話ユーザーインタフェースだけを提供するシステムに関する問題でしょう。 目的地システムに配送を許して、実装特有の手段でroutable FQDNアドレスへのダイヤルされた目標番号に関するマッピングを達成できます。
To facilitate a local cache, an implementation may wish to populate local directories with the first and last names, as well as the senders' spoken name information extracted from received messages. Addresses or names parsed from the header fields of VPIM messages MAY be used to populate directories.
ローカルなキャッシュを容易にするために、実装は1番目でローカルディレクトリに居住したがっているかもしれません、そして、姓、および送付者は受信されたメッセージから抜粋された名前情報を話しました。 VPIMメッセージのヘッダーフィールドから分析されたアドレスか名前が、ディレクトリに居住するのに使用されるかもしれません。
7. Management Protocols
7. 管理プロトコル
The Internet protocols provide a mechanism for the management of messaging systems, from the management of the physical network through the management of the message queues. SNMP SHOULD be supported on a VPIM-conforming machine.
インターネットプロトコルはメッセージシステムの管理にメカニズムを提供します、物理ネットワークの経営からメッセージキューの管理で。 SNMP SHOULD、VPIM-従うマシンの上でサポートされてください。
Vaudreuil & Parsons Standards Track [Page 30] RFC 3801 VPIMv2 June 2004
ボードルイと教区牧師標準化過程[30ページ]RFC3801VPIMv2 June 2004
7.1. Network Management
7.1. ネットワークマネージメント
The digital interface to the VM and the TCP/IP protocols MAY be managed. MIB II MAY be implemented to provide basic statistics and reporting of TCP and IP protocol performance [MIB II].
VMへのデジタルインタフェースとTCP/IPプロトコルは管理されるかもしれません。 基本的な統計を提供するために実装されて、TCPとIPについて報告するMIB II MAYが性能[MIB II]について議定書の中で述べます。
8. Conformance Requirements
8. 順応要件
VPIM is a messaging application that will be supported in several environments and be supported on differing devices. These environments include traditional voice processing systems, desktop voice messaging systems, store-and-forward relays, and protocol translation gateways.
VPIMはいくつかの環境でサポートされて、異なったデバイスでサポートされるメッセージングアプリケーションです。 これらの環境は伝統的な音声処理システム、デスクトップ声のメッセージシステム、店とフォワードリレー、およびプロトコル変換ゲートウェイを含んでいます。
In order to accommodate all environments, this document defines two areas of conformance: transport and content.
すべての環境を収容するために、このドキュメントは順応の2つの領域を定義します: 輸送と内容。
Transport-conformant systems will pass VPIM messages in a store-and- forward manner with assured delivery notifications and without the loss of information. It is expected that most store-and-forward Internet mail-based messaging systems will be VPIM transport- conformant.
そして、輸送-conformantシステムが店でメッセージをVPIMに通過する、-、-確実な配送通知と情報の損失なしで方法を進めてください。 ほとんどの店とフォワードのインターネットのメールベースのメッセージシステムがVPIM輸送conformantになると予想されます。
Content-conformant systems will generate and interpret VPIM messages. Conformance in the generation of VPIM messages indicates that the restrictions of this profile are honored. Only contents specified in this profile or extensions agreed to by bilateral agreement may be sent. Conformance in the interpretation of VPIM messages indicates that all VPIM content types and constructs can be received; that all mandatory VPIM content types can be decoded and presented to the recipient in an appropriate manner; and that any unrenderable contents result in the appropriate notification.
内容-conformantシステムは、VPIMメッセージを生成して、解釈するでしょう。 VPIMメッセージの世代における順応は、このプロフィールの制限が光栄に思っているのを示します。 このプロフィールで指定されたコンテンツか二国間条約によって同意された拡大だけを送るかもしれません。 VPIMメッセージの解釈における順応は、すべてのVPIM content typeと構造物を受け取ることができるのを示します。 適切な方法ですべての義務的なVPIM content typeを受取人に解読して、提示できます。 そして、どんな非レンダリング可能内容も適切な通知をもたらします。
A summary of the conformance requirements is contained in Appendix A.
順応要件の概要はAppendix Aに含まれています。
VPIM end systems are expected to be both transport- and content- conformant. Voice messaging systems and protocol conversion gateways are considered end systems.
VPIMエンドシステムは輸送と内容conformantの両方であると予想されます。 声のメッセージシステムとプロトコル変換ゲートウェイはエンドシステムであると考えられます。
Relay systems are expected to be transport-conformant in order to receive and send conforming messages. However, they must also create VPIM-conforming delivery status notifications in the event of delivery problems.
リレー方式はメッセージを従わせながら受信して、発信する輸送-conformantであると予想されます。 しかしながら、また、彼らは配送問題の場合、VPIM-従う配送状態通知を作成しなければなりません。
Desktop Email clients that support VPIM are expected to be content- conformant. Desktop email clients use various protocols and API's for exchanging messages with the local message store and message transport system. While these clients may benefit from VPIM
VPIMをサポートするデスクトップメールクライアントは内容conformantであると予想されます。 デスクトップメールクライアントは、地方のメッセージ店とメッセージ輸送システムとメッセージを交換するのに様々なプロトコルとAPIのものを使用します。 これらのクライアントはVPIMの利益を得るかもしれませんが
Vaudreuil & Parsons Standards Track [Page 31] RFC 3801 VPIMv2 June 2004
ボードルイと教区牧師標準化過程[31ページ]RFC3801VPIMv2 June 2004
transport capabilities, specific client-server requirements are out- of-scope for this document.
能力を輸送してください、そして、特定のクライアント/サーバ要件はこのドキュメントのために範囲で出ています。
9. Security Considerations
9. セキュリティ問題
9.1. General Directive
9.1. 一般指示
This document is a profile of existing Internet mail protocols. To maintain interoperability with Internet mail, any security to be provided should be part of the Internet security infrastructure, rather than a new mechanism or some other mechanism outside of the Internet infrastructure.
このドキュメントは既存のインターネットメールプロトコルのプロフィールです。 インターネット・メールがある相互運用性を維持するために、提供されるどんなセキュリティも新しいメカニズムか外のある他のメカニズムよりむしろインターネット基盤のインターネットセキュリティインフラストラクチャの一部であるべきです。
9.2. Threats and Problems
9.2. 脅威と問題
Both Internet mail and voice messaging have their own set of threats and countermeasures. As such, this specification does not create any security issues not already existing in the profiled Internet mail and voice mail protocols themselves. This section attends only to the set of additional threats that ensue from integrating the two services.
インターネット・メールと声のメッセージングの両方には、それら自身の脅威と対策のセットがあります。 そういうものとして、この仕様は輪郭を描かれたインターネット・メールとボイスメールプロトコル自体で既に存在しない少しの安全保障問題も作成しません。 このセクションは2つのサービスを統合するので続く追加脅威のセットだけに気を配ります。
9.2.1. Spoofed sender
9.2.1. 送付者であると偽造されます。
The actual sender of the voice message might not be the same as that specified in the "Sender:" or "From:" message header fields or the MAIL FROM address from the SMTP envelope. In a tightly constrained environment, sufficient physical and software controls may be able to ensure prevention of this problem. In addition, the recognition of the sender's voice may provide confidence of the sender's identity irrespective of that specified in "Sender:" or "From:". It should be recognized that SMTP implementations do not provide inherent authentication of the senders of messages, nor are sites under obligation to provide such authentication.
音声メールの実際の送付者が指定されたそれと同じでないかもしれない、「送付者:」 または、「From:」 SMTP封筒からのメッセージヘッダーフィールドかMAIL FROMアドレス。 しっかり強制的な環境で、物理的、そして、ソフトウェアの十分な制御装置はこの問題の防止を確実にすることができるかもしれません。 さらに、送付者の声の認識が指定されたそれの如何にかかわらず送付者のアイデンティティの信用を供給するかもしれない、「送付者:」 または、「From:。」 SMTP実装がメッセージの送付者の固有の認証を提供しないで、そのような認証を提供する義務の下のサイトであると認められるべきです。
9.2.2. Unsolicited voice mail
9.2.2. 求められていないボイスメール
Assigning an Internet mail address to a voice mailbox opens the possibility of receiving unsolicited messages (either text or voice mail). Traditionally, voice mail systems operated in closed environments and were not susceptible to unknown senders. Voice mail users have a higher expectation of mailbox privacy and may consider such messages as a security breach. Many Internet mail systems are choosing to block all messages from unknown sources in an attempt to curb this problem.
インターネット郵便の宛先をボイス・メールボックスに割り当てると、お節介なメッセージ(テキストかボイスメールのどちらか)を受け取る可能性は開きます。 ボイスメールシステムは、伝統的に、閉じている環境で作動して、見知らぬ送信者には、影響されやすくはありませんでした。 ボイスメールユーザは、メールボックスプライバシーへの、より高い期待を持って、そのようなメッセージが機密保護違反であるとみなすかもしれません。 多くのインターネット・メールシステムが、この問題を制限する試みで未知の情報源からのすべてのメッセージを妨げるのを選んでいます。
Vaudreuil & Parsons Standards Track [Page 32] RFC 3801 VPIMv2 June 2004
ボードルイと教区牧師標準化過程[32ページ]RFC3801VPIMv2 June 2004
9.2.3. Message disclosure
9.2.3. メッセージ公開
Users of voice messaging systems have an expectation of a level of message privacy that is higher than the level provided by Internet mail without security enhancements. This expectation of privacy by users SHOULD be preserved as much as possible.
声のメッセージシステムのユーザには、セキュリティ増進なしでインターネット・メールによって提供されたレベルより高いメッセージプライバシーのレベルへの期待があります。 この期待、ユーザSHOULDによるプライバシーでは、できるだけ保存されてください。
9.3. Security Techniques
9.3. セキュリティのテクニック
Sufficient physical and software control may be acceptable in constrained environments. Further, the profile specified in this document does not in any way preclude the use of any Internet object or channel security protocol to encrypt, authenticate, or non- repudiate the messages.
物理的、そして、ソフトウェアの十分な制御装置は強制的な環境で許容できるかもしれません。 さらに、本書では指定されたプロフィールが何らかの方法で暗号化するどんなインターネットオブジェクトやチャンネルセキュリティプロトコルの使用も排除しない、認証、非、メッセージを否認してください。
10. Normative References
10. 引用規格
[8BIT] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D.
Crocker, "SMTP Service Extension for 8bit-MIMEtransport",
RFC 1652, July 1994.
Klensin(J.)が解放した[8ビット]、N.、ローズ、M.、Stefferud、E.、およびD.クロッカー、「SMTPは8ビット-MIMEtransportのために拡大を修理します」、RFC1652、1994年7月。
[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月。
[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、問題3、1993年8月。
[BINARY] Vaudreuil, G., "SMTP Service Extensions for Transmission of
Large and Binary MIME Messages", RFC 3030, December 2000.
[2進]のボードルイ、G.、「大きくて2進のMIMEメッセージの伝達のためのSMTPサービス拡張子」、RFC3030、2000年12月。
[CODES] Vaudreuil, G. "Enhanced Mail System Status Codes", RFC
1893, January 1996.
[コード] ボードルイ、G.「高められたメールシステムステータスコード」、RFC1893、1996年1月。
[MIMEDIR] Dawson, F., Howes, T. and M. Smith, "A MIME Content-Type
for Directory Information", RFC 2425, September 1998.
[MIMEDIR] ドーソンとF.とハウズとT.とM.スミス、「ディレクトリ情報のためのMIMEコンテントタイプ」、RFC2425、1998年9月。
[DISP] Troost, R. and S. Dorner, "Communicating Presentation
Information in Internet Messages: The Content-Disposition
Header", RFC 2183, August 1997.
[DISP] Troost、R.、およびS.デルナー、「インターネットでプレゼンテーション情報を伝えるのは通信します」。 「満足している気質ヘッダー」、RFC2183、1997年8月。
[DNS1] Mockapetris, P., "Domain names - implementation and
specification", RFC 1035, November 1987.
[DNS1]Mockapetris、P.、「ドメイン名--、実現と仕様、」、RFC1035、11月1987日
Vaudreuil & Parsons Standards Track [Page 33] RFC 3801 VPIMv2 June 2004
ボードルイと教区牧師標準化過程[33ページ]RFC3801VPIMv2 June 2004
[DNS2] Mockapetris, P., "Domain names - concepts and facilities",
RFC 1034, November 1987.
[DNS2]Mockapetris、P.、「ドメイン名--、概念と施設、」、RFC1034、11月1987日
[DRPT] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service
Extension for Delivery Status Notifications (DSNs)", RFC
3461, January 2003.
[DRPT]ムーア、K.、「配送状態通知(DSNs)のためのシンプルメールトランスファプロトコル(SMTP)サービス拡大」、RFC3461、2003年1月。
[DSN] Moore, K. and G. Vaudreuil, "An Extensible Message Format
for Delivery Status Notifications", RFC 3464, January 2003.
[DSN] ムーアとK.とG.ボードルイ、「配送状態通知のための広げることができるメッセージ・フォーマット」、RFC3464、2003年1月。
[DUR] Parsons, G. and G. Vaudreuil, "Content Duration MIME Header
Definition", RFC 3803, June 2004.
[DUR] パーソンズとG.とG.ボードルイ、「満足している持続時間MIMEヘッダー定義」、RFC3803、2004年6月。
[E164] CCITT Recommendation E.164 (1991), Telephone Network and
ISDN Operation, Numbering, Routing and Mobile Service -
Numbering Plan for the ISDN Era.
[164E]のCCITT推薦E.164(1991)、電話網、ISDN操作、付番、ルート設定、およびモバイルサービス--ISDN時代のためのプランに付番します。
[ESMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
April 2001.
[ESMTP] Klensin、J.、「簡単なメール転送プロトコル」、RFC2821、2001年4月。
[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)。
[HOSTREQ] Braden, R., "Requirements for Internet Hosts -- Application
and Support", STD 3, RFC 1123, October 1989.
[HOSTREQ]ブレーデン、R.、「インターネットホストのための要件--、アプリケーションとサポート、」、STD3、RFC1123、10月1989日
[LANG] Alvestrand, H., "Tags for the Identification of Languages",
BCP 47, RFC 3066, January 2001.
[ラング]Alvestrand、H.、「言語の識別のためのタグ」、BCP47、RFC3066、2001年1月。
[MDN] Hansen, T., Ed. and G. Vaudreuil, Ed., "Message Disposition
Notification", RFC 3798, May 2004.
エド[MDN]ハンセン、T.、G.ボードルイ、エド、「メッセージ気質通知」、RFC3798、5月2004日
[MIB II] Rose, M., "Management Information Base for Network
Management of TCP/IP-based internets: MIB-II", RFC 1213,
March 1991.
[MIB II]ローズ、M.、「TCP/IPベースのインターネットのNetwork Managementのための管理Information基地:」 「MIB-II」、RFC1213、1991年3月。
[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月。
Vaudreuil & Parsons Standards Track [Page 34] RFC 3801 VPIMv2 June 2004
ボードルイと教区牧師標準化過程[34ページ]RFC3801VPIMv2 June 2004
[MIME3] Moore, K., "Multipurpose Internet Mail Extensions (MIME)
Part Three: Message Header Extensions for Non-ASCII Text ",
RFC 2047, November 1996.
[MIME3]ムーア、K.、「マルチパーパスインターネットメールエクステンション(MIME)は3を分けます」。 「非ASCIIテキストのためのメッセージヘッダー拡張子」、RFC2047、1996年11月。
[MIME4] Freed, N., Klensin, J. and J. Postel, "Multipurpose
Internet Mail Extensions (MIME) Part Four: Registration
Procedures", RFC 2048, November 1996.
解放された[MIME4]、N.、Klensin、J.、およびJ.ポステル、「マルチパーパスインターネットメールエクステンション(MIME)は4を分けます」。 「登録手順」、RFC2048、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日
[PIPE] Freed, N.and A. Cargille, "SMTP Service Extension for
Command Pipelining" STD 60, RFC 2920, September 2000.
解放された[パイプ]とN.とA.Cargille、「コマンド連続送信のためのSMTPサービス拡張子」STD60、2000年9月のRFC2920。
[REPORT] Vaudreuil, G., "The Multipart/Report Content Type for the
Reporting of Mail System Administrative Messages", RFC
3462, January 2003.
[報告します] ボードルイ、G.、「メールのシステムの管理メッセージの報告のための複合/レポート満足しているタイプ」、RFC3462、2003年1月。
[REQ] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[REQ] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC822] Crocker, D., "Standard for the Format of ARPA Internet Text
Messages", STD 11, RFC 822, August 1982.
[RFC822] クロッカー、D.、「アルパインターネットテキスト・メッセージの形式の規格」、STD11、RFC822、1982年8月。
[SIZE] Klensin, J., Freed, N. and K. Moore, "SMTP Service
Extensions for Message Size Declaration" STD 10, RFC 1870,
November 1995.
Klensin(J.)が解放した[サイズ]とN.とK.ムーア、「メッセージサイズ宣言のためのSMTPサービス拡張子」STD10、RFC1870(1995年11月)。
[STATUS] Freed, N., "SMTP Service Extension for Returning Enhanced
Error Codes", RFC 2034, October 1996.
解放された[状態]、N.、「戻るためのSMTPサービス拡張子はエラーコードを高めた」RFC2034、1996年10月。
[TIFF-F] Parsons, G. and J. Rafferty, "Tag Image File Format:
Application F", RFC 2306, March 1998.
[いさかいF]のパーソンズ、G.、およびJ.Rafferty、「画像ファイル形式にタグ付けをしてください」 「アプリケーションF」、RFC2306、1998年3月。
[TIFFREG] Parsons, G., Rafferty, J. and S. Zilles, "Tag Image File
Format: image/tiff - MIME sub-type registration", RFC 2302,
March 1998.
[TIFFREG] パーソンズ、G.、Rafferty、J.、およびS.Zilles、「画像ファイル形式にタグ付けをしてください」 「/いさかいに像を描いてください--MIMEサブタイプ登録」、RFC2302、3月1998日
[V-MSG] Vaudreuil, G. and G. Parsons, "VPIM Voice Message MIME
Sub-type Registration", RFC 2423, September 1998.
[V-MSG] ボードルイとG.とG.パーソンズ、「VPIM音声メールMIMEサブタイプ登録」、RFC2423、1998年9月。
[VCARD] Dawson, F. and T. Howes, "vCard MIME Directory Profile" RFC
2426, September 1998.
[VCARD]ドーソンとF.とT.ハウズ、「vCard MIMEディレクトリプロフィール」RFC2426、1998年9月。
[VPIM1] Vaudreuil, G., "Voice Profile for Internet Mail", RFC 1911,
February 1996.
[VPIM1] ボードルイ、G.、「インターネットメールのための声のプロフィール」、RFC1911、1996年2月。
Vaudreuil & Parsons Standards Track [Page 35] RFC 3801 VPIMv2 June 2004
ボードルイと教区牧師標準化過程[35ページ]RFC3801VPIMv2 June 2004
[VPIM2] Vaudreuil, G. and G. Parsons, "Voice Profile for Internet
Mail, Version 2", RFC 2421, September 1998.
[VPIM2] ボードルイ、G.、およびG.パーソンズは「1998年9月にインターネットメール、バージョン2インチ、RFC2421のためにプロフィールを声に出します」。
[X.400] CCITT/ISO, "CCITT Recommendations X.400/ ISO/IEC 10021-1,
Message Handling: System and Service Overview", December
1988.
[X.400]CCITT/ISO、「CCITT推薦X.400/ISO/IEC10021-1、メッセージハンドリング:」 1988年12月の「システムとサービス概観」
11. Acknowledgments
11. 承認
The authors would like to offer a special thanks to the Electronic Messaging Association (EMA), especially the members of the Voice Messaging Committee, and the IETF VPIM Work Group, for their support of the VPIM specification and the efforts they have made to ensure its success.
作者は特にElectronic Messaging Association(EMA)、Voice Messaging Committeeのメンバー、およびIETF VPIM Work Groupのおかげで特別番組を提供したがっています、彼らのVPIM仕様のサポートとそれらが成功を確実にするためにした努力のために。
Vaudreuil & Parsons Standards Track [Page 36] RFC 3801 VPIMv2 June 2004
ボードルイと教区牧師標準化過程[36ページ]RFC3801VPIMv2 June 2004
12. Appendix A - VPIM Requirements Summary
12. 付録A--VPIM要件概要
The following table summarizes the profile of VPIM version 2 detailed in this document. Since in many cases it is not possible to simplify the qualifications for supporting each feature this appendix is informative. The reader is recommended to read the complete explanation of each feature in the referenced section. The text in the previous sections shall be deemed authoritative if any item in this table is ambiguous.
以下のテーブルはこのドキュメントで詳細なVPIMバージョン2のプロフィールをまとめます。 各特徴を支持するために資格を簡素化するのが多くの場合可能でないので、この付録は有益です。 読者は参照をつけられたセクションのそれぞれの特徴に関する完璧な説明を読むためにお勧めです。 このテーブルの何か項目があいまいであるなら、前項のテキストは正式であると考えられるものとします。
The conformance table is separated into various columns:
順応テーブルは様々なコラムに切り離されます:
Feature - name of protocol feature (note that the indenting
indicates a hierarchy of conformance, i.e., the
conformance of a lower feature is only relevant if there
is conformance to the higher feature)
特徴--プロトコル機能の名前(入り込むのが順応の階層構造を示して、すなわち、より高い特徴への順応がある場合にだけ下側の特徴の順応が関連しているというメモ)
Section - reference section in main text of this document
セクション--このドキュメントの主な原本の参照部
Area - conformance area to which each feature applies:
C - content
T - transport
領域--各特徴が適用される順応領域: C--内容T--輸送
Status - whether the feature is mandatory, optional, or prohibited. The key words used in this table are to be interpreted as described in [REQ], though the following list gives a quick overview of the different degrees of feature conformance:
状態--特徴は、義務的ですか、任意ですか、または禁止されていますか? このテーブルで使用されるキーワードは[REQ]で説明されるように解釈されることです、以下のリストは異なった度の特徴順応の迅速な概観を与えますが:
Must - mandatory
Should - required in the absence of a compelling
need to omit.
May - optional
Should not - prohibited in the absence of a compelling
need.
Must not - prohibited
省略する無視できない必要性がないとき必要であることで(義務的なShould)、そうしなければなりません。 5月--、任意のShould、--無視できない必要性がないとき、禁止されています。 禁止しなければなりません。
Footnote - special comment about conformance for a particular feature
脚注--特定の特徴のための順応に関する特別なコメント
Vaudreuil & Parsons Standards Track [Page 37] RFC 3801 VPIMv2 June 2004
ボードルイと教区牧師標準化過程[37ページ]RFC3801VPIMv2 June 2004
VPIM version 2 Conformance
| | | | |S| |
| | | | | |H| |F
| | | | | |O|M|o
| | | |S| |U|U|o
| | | |H| |L|S|t
| |A|M|O| |D|T|n
| |R|U|U|M| | |o
| |E|S|L|A|N|N|t
| |A|T|D|Y|O|O|t
FEATURE |SECTION | | | | |T|T|e
-------------------------------------------|----------|-|-|-|-|-|-|-
| | | | | | | |
Message Addressing Formats: | | | | | | | |
Use DNS host names |4.1 |C|x| | | | |
Use only numbers in mailbox IDs |4.1.1 |C| |x| | | |
Numbers in mailbox IDs follow E.164 |4.1.1 |C| |x| | | |
Use alpha-numeric mailbox IDs |4.1.1 |C| | |x| | |
Support of postmaster@domain |4.1.2 |C|x| | | | |
Support of non-mail-user@domain |4.1.2 |C| |x| | | |
Support of distribution lists |4.1.3 |C| | |x| | |
| | | | | | | |
Message Header Fields: | | | | | | | |
Sending outbound messages | | | | | | | |
From |4.2.1 |C|x| | | | |
Addition of text name |4.2.1 |C| |x| | | |
Same value as MAIL FROM |4.2.1 |C| |x| | | |
To |4.2.2 |C| |x| | | |1
cc |4.2.3 |C| | |x| | |1
Date |4.2.4 |C|x| | | | |
Sender |4.2.5 |C| | |x| | |
Return-Path |4.2.6 |C| | | | |x|
Message-ID |4.2.7 |C|x| | | | |
Reply-To |4.2.8 |C| | | |x| |
Received |4.2.9 |C|x| | | | |
MIME Version: 1.0 (Voice 2.0) |4.2.10 |C| |x| | | |
Content-Type |4.2.11 |C|x| | | | |
Content-Transfer-Encoding |4.2.12 |C|x| | | | |
Sensitivity |4.2.13 |C| | |x| | |
Importance |4.2.14 |C| | |x| | |
Subject |4.2.15 |C| |x| | | |
Disposition-notification-to |4.7 |C| |x| | | |
Other Headers |4.2 |C| | |x| | |
| | | | | | | |
VPIMバージョン2 Conformance| | | | |S| | | | | | | |H| |F| | | | | |O|M|o | | | |S| |U|U|o | | | |H| |L|S|t| |A|M|O| |D|T|n| |R|U|U|M| | |o | |E|S|L|A|N|N|t| |A|T|D|Y|O|O|t FEATURE|セクション| | | | |T|T|e-------------------------------------------|----------|-|-|-|-|-|-|- | | | | | | | | メッセージアドレス指定形式: | | | | | | | | DNSホスト名を使用してください。|4.1 |C|x| | | | | メールボックスIDに数だけを使用してください。|4.1.1 |C| |x| | | | メールボックスIDにおける数はE.164に続きます。|4.1.1 |C| |x| | | | アルファベット数字式メールボックスIDを使用してください。|4.1.1 |C| | |x| | | postmaster@domain のサポート|4.1.2 |C|x| | | | | non-mail-user@domain のサポート|4.1.2 |C| |x| | | | 発送先リストのサポート|4.1.3 |C| | |x| | | | | | | | | | | メッセージヘッダーフィールド: | | | | | | | | 送付の外国行きのメッセージ| | | | | | | | from|4.2.1 |C|x| | | | | 原文名の添加|4.2.1 |C| |x| | | | MAIL FROMと同じ値|4.2.1 |C| |x| | | | to|4.2.2 |C| |x| | | |1cc|4.2.3 |C| | |x| | |1つの日付|4.2.4 |C|x| | | | | 送付者|4.2.5 |C| | |x| | | リターンパス|4.2.6 |C| | | | |x| Message ID|4.2.7 |C|x| | | | | 答えます。|4.2.8 |C| | | |x| | 受信します。|4.2.9 |C|x| | | | | バージョンをまねてください: 1.0 (声2.0)|4.2.10 |C| |x| | | | コンテントタイプ|4.2.11 |C|x| | | | | 満足している転送コード化|4.2.12 |C|x| | | | | 感度|4.2.13 |C| | |x| | | 重要性|4.2.14 |C| | |x| | | 対象|4.2.15 |C| |x| | | | 気質通知|4.7 |C| |x| | | | 他のヘッダー|4.2 |C| | |x| | | | | | | | | | |
Vaudreuil & Parsons Standards Track [Page 38] RFC 3801 VPIMv2 June 2004
ボードルイと教区牧師標準化過程[38ページ]RFC3801VPIMv2 June 2004
| | | | | |H| |F
| | | | | |O|M|o
| | | |S| |U|U|o
| | | |H| |L|S|t
| |A|M|O| |D|T|n
| |R|U|U|M| | |o
| |E|S|L|A|N|N|t
| |A|T|D|Y|O|O|t
FEATURE |SECTION | | | | |T|T|e
-------------------------------------------|----------|-|-|-|-|-|-|-
Receiving inbound messages | | | | | | | |
From |4.2.1 |C|x| | | | |
Present text personal name |4.2.1 |C| | |x| | |
To |4.2.2 |C|x| | | | |
cc |4.2.3 |C| | |x| | |
Date |4.2.4 |C|x| | | | |
Conversion of Date to local time |4.2.4 |C| |x| | | |
Sender |4.2.5 |C| | |x| | |
Return-Path |4.2.6 |C| |x| | | |
Message-ID |4.2.7 |C| | |x| | |
MDN requested |4.2.7 |C|x| | | | |
Reply-To |4.2.8 |C| | |x| | |
Received |4.2.9 |C| | |x| | |
MIME Version: 1.0 (Voice 2.0) |4.2.10 |C| |x| | | |
Content Type |4.2.11 |C|x| | | | |
Content-Transfer-Encoding |4.2.12 |C|x| | | | |
Sensitivity |4.2.13 |C|x| | | | |2
Importance |4.2.14 |C| | |x| | |
Subject |4.2.15 |C| | |x| | |
Disposition-notification-to |4.7 |C| |x| | | |
Other Headers |4.2 |C|x| | | | |3
| | | | | | | |
Message Content Encoding: | | | | | | | |
Sending outbound audio/fax contents | | | | | | | |
7BIT |4.2.12 |C| | | | |x|
8BIT |4.2.12 |C| | | | |x|
Quoted Printable |4.2.12 |C| | | | |x|
Base64 |4.2.12 |C|x| | | | |4
Binary |4.2.12 |C| |x| | | |5
Receiving inbound message contents | | | | | | | |
7BIT |4.2.12 |C|x| | | | |
8BIT |4.2.12 |C|x| | | | |
Quoted Printable |4.2.12 |C|x| | | | |
Base64 |4.2.12 |C|x| | | | |
Binary |4.2.12 |C|x| | | | |5
| | | | | | | |
| | | | | |H| |F| | | | | |O|M|o | | | |S| |U|U|o | | | |H| |L|S|t| |A|M|O| |D|T|n| |R|U|U|M| | |o | |E|S|L|A|N|N|t| |A|T|D|Y|O|O|t FEATURE|セクション| | | | |T|T|e-------------------------------------------|----------|-|-|-|-|-|-|- 本国行きのメッセージを受け取ります。| | | | | | | | from|4.2.1 |C|x| | | | | 現在のテキスト個人名|4.2.1 |C| | |x| | | to|4.2.2 |C|x| | | | | cc|4.2.3 |C| | |x| | | 日付|4.2.4 |C|x| | | | | 現地時間までのDateの変換|4.2.4 |C| |x| | | | 送付者|4.2.5 |C| | |x| | | リターンパス|4.2.6 |C| |x| | | | Message ID|4.2.7 |C| | |x| | | 要求されたMDN|4.2.7 |C|x| | | | | 答えます。|4.2.8 |C| | |x| | | 受信します。|4.2.9 |C| | |x| | | バージョンをまねてください: 1.0 (声2.0)|4.2.10 |C| |x| | | | 満足しているタイプ|4.2.11 |C|x| | | | | 満足している転送コード化|4.2.12 |C|x| | | | | 感度|4.2.13 |C|x| | | | |2 重要性|4.2.14 |C| | |x| | | 対象|4.2.15 |C| | |x| | | 気質通知|4.7 |C| |x| | | | 他のヘッダー|4.2 |C|x| | | | |3 | | | | | | | | メッセージ内容コード化: | | | | | | | | 送付の外国行きのオーディオ/ファックスコンテンツ| | | | | | | | 7ビット|4.2.12 |C| | | | |x| 8ビット|4.2.12 |C| | | | |x| 引用、印刷可能|4.2.12 |C| | | | |x| Base64|4.2.12 |C|x| | | | |4バイナリー|4.2.12 |C| |x| | | |5 本国行きのメッセージ内容を受け取ること。| | | | | | | | 7ビット|4.2.12 |C|x| | | | | 8ビット|4.2.12 |C|x| | | | | 引用、印刷可能|4.2.12 |C|x| | | | | Base64|4.2.12 |C|x| | | | | バイナリー|4.2.12 |C|x| | | | |5 | | | | | | | |
Vaudreuil & Parsons Standards Track [Page 39] RFC 3801 VPIMv2 June 2004
ボードルイと教区牧師標準化過程[39ページ]RFC3801VPIMv2 June 2004
| | | | |S| |
| | | | | |H| |F
| | | | | |O|M|o
| | | |S| |U|U|o
| | | |H| |L|S|t
| |A|M|O| |D|T|n
| |R|U|U|M| | |o
| |E|S|L|A|N|N|t
| |A|T|D|Y|O|O|t
FEATURE |SECTION | | | | |T|T|e
-------------------------------------------|----------|-|-|-|-|-|-|-
Message Content Types: | | | | | | | |
Sending outbound messages | | | | | | | |
Multipart/Voice-Message |4.4.1 |C|x| | | | |
Message/RFC822 |4.4.2 |C| |x| | | |
Audio/32KADPCM |4.4.3 |C|x| | | | |
Content-Description |4.3.1 |C| | |x| | |
Content-Disposition |4.3.2 |C|x| | | | |
Content-Duration |4.3.3 |C| | |x| | |
Content-Language |4.3.4 |C| | |x| | |
Image/TIFF; application=faxbw |4.4.4 |C|x| | | | |7
Text/Directory |4.5.2 |C| | | |x| |9
Text/plain |4.5.4 |C| | | |x| |
Audio/* or Image/* (other encodings) |4.5.3 |C| | | |x| |
Other contents |4.5 |C| | | | |x|
Multipart/Mixed |4.5.1 |C| | |x| | |
Text/plain |4.5.4 |C| | |x| | |
Multipart/Report |4.6, 4.7 |C|x| | | | |
human-readable part is voice |4.6, 4.7 |C| |x| | | |
human-readable part is text |4.6, 4.7 |C| | |x| | |
Message/Delivery-Status |4.6 |C|x| | | | |
Message/Disposition-Notification |4.7 |C| |x| | | |
Other contents |4.5 |C| | | |x| |6
| | | | |S| | | | | | | |H| |F| | | | | |O|M|o | | | |S| |U|U|o | | | |H| |L|S|t| |A|M|O| |D|T|n| |R|U|U|M| | |o | |E|S|L|A|N|N|t| |A|T|D|Y|O|O|t FEATURE|セクション| | | | |T|T|e-------------------------------------------|----------|-|-|-|-|-|-|- メッセージ内容は以下をタイプします。 | | | | | | | | 送付の外国行きのメッセージ| | | | | | | | 複合かメッセージを声に出します。|4.4.1 |C|x| | | | | メッセージ/RFC822|4.4.2 |C| |x| | | | オーディオ/32KADPCM|4.4.3 |C|x| | | | | 満足している記述|4.3.1 |C| | |x| | | 満足している気質|4.3.2 |C|x| | | | | 満足している持続時間|4.3.3 |C| | |x| | | 満足している言語|4.3.4 |C| | |x| | | イメージ/いさかい。 アプリケーションはfaxbwと等しいです。|4.4.4 |C|x| | | | |7 テキスト/ディレクトリ|4.5.2 |C| | | |x| |9 テキスト/平野|4.5.4 |C| | | |x| | オーディオ/*かImage/*(他のencodings)|4.5.3 |C| | | |x| | 他のコンテンツ|4.5 |C| | | | |x| 複合か混ぜられます。|4.5.1 |C| | |x| | | テキスト/平野|4.5.4 |C| | |x| | | 複合/レポート|4.6, 4.7 |C|x| | | | | 人間読み込み可能な部分は声です。|4.6, 4.7 |C| |x| | | | 人間読み込み可能な部分はテキストです。|4.6, 4.7 |C| | |x| | | 配送メッセージ/状態|4.6 |C|x| | | | | 気質メッセージ/通知|4.7 |C| |x| | | | 他のコンテンツ|4.5 |C| | | |x| |6
Receiving in inbound messages | | | | | | | |
Multipart/Voice-Message |4.4.1 |C|x| | | | |
Message/RFC822 |4.4.2 |C|x| | | | |
Audio/32KADPCM |4.4.3 |C|x| | | | |
Content-Description |4.3.1 |C| | |x| | |
Content-Disposition |4.3.2 |C| |x| | | |
Content-Duration |4.3.3 |C| | |x| | |
Content-Language |4.3.4 |C| | |x| | |
Image/TIFF; application=faxbw |4.4.4 |C| |x| | | |8
Text/Directory |4.5.2 |C|x| | | | |9
Text/plain |4.5.4 |C| | |x| | |
Audio/* or Image/* (other encodings) |4.5.3 |C| | |x| | |
Other contents |4.5 |C| | |x| | |
Multipart/Mixed |4.5.1 |C| | |x| | |
本国行きのメッセージでは、受信します。| | | | | | | | 複合かメッセージを声に出します。|4.4.1 |C|x| | | | | メッセージ/RFC822|4.4.2 |C|x| | | | | オーディオ/32KADPCM|4.4.3 |C|x| | | | | 満足している記述|4.3.1 |C| | |x| | | 満足している気質|4.3.2 |C| |x| | | | 満足している持続時間|4.3.3 |C| | |x| | | 満足している言語|4.3.4 |C| | |x| | | イメージ/いさかい。 アプリケーションはfaxbwと等しいです。|4.4.4 |C| |x| | | |8 テキスト/ディレクトリ|4.5.2 |C|x| | | | |9 テキスト/平野|4.5.4 |C| | |x| | | オーディオ/*かImage/*(他のencodings)|4.5.3 |C| | |x| | | 他のコンテンツ|4.5 |C| | |x| | | 複合か混ぜられます。|4.5.1 |C| | |x| | |
Vaudreuil & Parsons Standards Track [Page 40] RFC 3801 VPIMv2 June 2004
ボードルイと教区牧師標準化過程[40ページ]RFC3801VPIMv2 June 2004
| | | | | |S| |
| | | | | |H| |F
| | | | | |O|M|o
| | | |S| |U|U|o
| | | |H| |L|S|t
| |A|M|O| |D|T|n
| |R|U|U|M| | |o
| |E|S|L|A|N|N|t
| |A|T|D|Y|O|O|t
FEATURE |SECTION | | | | |T|T|e
------------------------------------------|-----------|-|-|-|-|-|-|-
| | | | | | | |
Text/plain |4.5.4 |C|x| | | | |
Multipart/Report |4.6, 4.7 |C|x| | | | |
human-readable part is voice |4.6, 4.7 |C|x| | | | |
human-readable part is text |4.6, 4.7 |C|x| | | | |
Message/Delivery-Status |4.6 |C|x| | | | |
Message/Disposition-Notification |4.7 |C| |x| | | |
Other contents |4.5 |C| | |x| | |6
| | | | | | | |
Forwarded Messages | | | | | | | |
use Message/RFC822 construct |4.8 |C| |x| | | |
simulate headers if none available |4.8 |C| |x| | | |
| | | | | | | |
Reply Messages |4.9 |C|x| | | | |
send to Reply-To, else From address |4.2.8 |C| | |x| | |
send to non-mail-user |4.9 |C| | | |x| |
| | | | | | | |
Notifications | | | | | | | |
use Multipart/Report format |4.6, 4.7 |C|x| | | | |
always send error on non-delivery |4.6 |C|x| | | | |
send error messages to return-path |4.2.6 |C|x| | | | |
| | | | | | | |
Message Transport Protocol: | | | | | | | |
Base ESMTP Commands | | | | | | | |
HELO |5.1 |T|x| | | | |
MAIL FROM |5.1 |T|x| | | | |
RCPT TO |5.1 |T|x| | | | |
DATA |5.1 |T|x| | | | |
TURN |5.1 |T| | | | |x|
QUIT |5.1 |T|x| | | | |
RSET |5.1 |T|x| | | | |
VRFY |5.1 |T| | |x| | |
EHLO |5.1 |T|x| | | | |
BDAT |5.1 |T| | |x| | |5
| | | | | |S| | | | | | | |H| |F| | | | | |O|M|o | | | |S| |U|U|o | | | |H| |L|S|t| |A|M|O| |D|T|n| |R|U|U|M| | |o | |E|S|L|A|N|N|t| |A|T|D|Y|O|O|t FEATURE|セクション| | | | |T|T|e------------------------------------------|-----------|-|-|-|-|-|-|- | | | | | | | | テキスト/平野|4.5.4 |C|x| | | | | 複合/レポート|4.6, 4.7 |C|x| | | | | 人間読み込み可能な部分は声です。|4.6, 4.7 |C|x| | | | | 人間読み込み可能な部分はテキストです。|4.6, 4.7 |C|x| | | | | 配送メッセージ/状態|4.6 |C|x| | | | | 気質メッセージ/通知|4.7 |C| |x| | | | 他のコンテンツ|4.5 |C| | |x| | |6 | | | | | | | | 転送されたメッセージ| | | | | | | | Message/RFC822が構成する使用|4.8 |C| |x| | | | 利用可能でないなにもであるヘッダーをシミュレートしてください。|4.8 |C| |x| | | | | | | | | | | | 応答メッセージ|4.9 |C|x| | | | | 発信する、Reply、-、ほかのFromアドレス|4.2.8 |C| | |x| | | 非メールのユーザに発信してください。|4.9 |C| | | |x| | | | | | | | | | 通知| | | | | | | | Multipart/レポート形式を使用してください。|4.6, 4.7 |C|x| | | | | 非配送のいつも送信エラー|4.6 |C|x| | | | | エラーメッセージをリターンパスに送ってください。|4.2.6 |C|x| | | | | | | | | | | | | メッセージ転送プロトコル: | | | | | | | | 基地のESMTPコマンド| | | | | | | | HELO|5.1 |T|x| | | | | メール|5.1 |T|x| | | | | RCPT|5.1 |T|x| | | | | データ|5.1 |T|x| | | | | 回転|5.1 |T| | | | |x| やめてください。|5.1 |T|x| | | | | RSET|5.1 |T|x| | | | | VRFY|5.1 |T| | |x| | | EHLO|5.1 |T|x| | | | | BDAT|5.1 |T| | |x| | |5
Vaudreuil & Parsons Standards Track [Page 41] RFC 3801 VPIMv2 June 2004
ボードルイと教区牧師標準化過程[41ページ]RFC3801VPIMv2 June 2004
| | | | |S| |
| | | | | |H| |F
| | | | | |O|M|o
| | | |S| |U|U|o
| | | |H| |L|S|t
| |A|M|O| |D|T|n
| |R|U|U|M| | |o
| |E|S|L|A|N|N|t
| |A|T|D|Y|O|O|t
FEATURE |SECTION | | | | |T|T|e
-------------------------------------------|----------|-|-|-|-|-|-|-
| | | | | | | |
ESMTP Keywords & Parameters | | | | | | | |
DSN |5.2.1 |T|x| | | | |
NOTIFY |5.2.1 |T|x| | | | |
RET |5.2.1 |T| |x| | | |
ENVID |5.2.1 |T| | |x| | |
ORCPT |5.2.1 |T| | |x| | |
SIZE |5.2.2 |T|x| | | | |
ENHANCEDSTATUSCODES |5.2.3 |T| |x| | | |
PIPELINING |5.2.4 |T| |x| | | |
CHUNKING |5.2.5 |T| | |x| | |
BINARYMIME |5.2.6 |T| | |x| | |
| | | | | | | |
ESMTP-SMTP Downgrading | | | | | | | |
send delivery report upon downgrade |5.3 |T|x| | | | |
| | | | | | | |
Directory Address Resolution | | | | | | | |
provide facility to resolve addresses |6 |C| |x| | | |
use headers to populate local directory |6 |C| | |x| | |
| | | | | | | |
Management Protocols: | | | | | | | |
Network management |7.1 |T| | |x| | |
-------------------------------------------|----------|-|-|-|-|-|-|-
| | | | |S| | | | | | | |H| |F| | | | | |O|M|o | | | |S| |U|U|o | | | |H| |L|S|t| |A|M|O| |D|T|n| |R|U|U|M| | |o | |E|S|L|A|N|N|t| |A|T|D|Y|O|O|t FEATURE|セクション| | | | |T|T|e-------------------------------------------|----------|-|-|-|-|-|-|- | | | | | | | | ESMTPキーワードとパラメタ| | | | | | | | DSN|5.2.1 |T|x| | | | | 通知してください。|5.2.1 |T|x| | | | | 浸水してください。|5.2.1 |T| |x| | | | ENVID|5.2.1 |T| | |x| | | ORCPT|5.2.1 |T| | |x| | | サイズ|5.2.2 |T|x| | | | | ENHANCEDSTATUSCODES|5.2.3 |T| |x| | | | パイプライン処理|5.2.4 |T| |x| | | | 分魂化|5.2.5 |T| | |x| | | BINARYMIME|5.2.6 |T| | |x| | | | | | | | | | | ESMTP-SMTP格下げ| | | | | | | | 配送レポートをダウングレードに送ってください。|5.3 |T|x| | | | | | | | | | | | | ディレクトリアドレス解決| | | | | | | | 施設を提供して、アドレスを決議してください。|6 |C| |x| | | | ヘッダーを使用して、ローカルディレクトリに居住してください。|6 |C| | |x| | | | | | | | | | | 管理プロトコル: | | | | | | | | ネットワークマネージメント|7.1 |T| | |x| | | -------------------------------------------|----------|-|-|-|-|-|-|-
Footnotes:
脚注:
1. SHOULD leave blank if all recipients are not known or resolvable.
2. If a sensitive message is received by a system that does not
support sensitivity, then it MUST be returned to the originator
with an appropriate error notification. Also, a received
sensitive message MUST NOT be forwarded to anyone.
3. If the additional header fields are not understood they MAY
be ignored.
4. When binary transport is not available.
5. When binary transport is available.
1. すべての受取人が知られているか、または溶解性であるというわけではないなら、SHOULDは空白を出ます。 2. 感度を支持しないシステムで機密のメッセージを受け取るなら、適切なエラー通知と共にそれを創始者に返さなければなりません。 また、受信された機密のメッセージをだれにも転送してはいけません。 3. 追加ヘッダーフィールドが理解されていないなら、それらは無視されるかもしれません。 4. 2進の輸送が利用可能でないときに。 5. 2進の輸送が利用可能であるときに。
Vaudreuil & Parsons Standards Track [Page 42] RFC 3801 VPIMv2 June 2004
ボードルイと教区牧師標準化過程[42ページ]RFC3801VPIMv2 June 2004
6. Other un-profiled contents MUST only be sent by bilateral
agreement.
7. If fax is supported.
8. If the fax content cannot be presented it MAY be dropped.
9. Handling of a vCard in text/directory is no longer defined.
6. 二国間条約は他の不-輪郭を描かれたコンテンツを送るだけでよいです。 7. ファックスが支えられるなら。 8. ファックス内容を提示できないなら、それは落とされるかもしれません。 9. テキスト/ディレクトリにおけるvCardの取り扱いはもう定義されません。
13. Appendix B - Example Voice Messages
13. 付録B--例の音声メール
The following message is a full-featured message addressed to two recipients. The message includes the sender's spoken name, spoken subject and a short speech segment. The message is marked as important and private.
以下のメッセージは2人の受取人まで記述された完全装備のメッセージです。 メッセージは送付者の話された名前、話された対象、および簡潔なスピーチセグメントを含んでいます。 メッセージは重要で個人的であるとしてマークされます。
To: +19725551212@vm1.mycompany.com
To: +16135551234@VM1.mycompany.com
From: "Parsons, Glenn" <12145551234@VM2.mycompany.com>
Date: Mon, 26 Aug 93 10:20:20 -0700 (CDT)
MIME-Version: 1.0 (Voice 2.0)
Content-type: Multipart/Voice-Message; Version=2.0;
Boundary="MessageBoundary"
Content-Transfer-Encoding: 7bit
Message-ID: 123456789@VM2.mycompany.com
Sensitivity: Private
Importance: High
To: + 19725551212@vm1.mycompany.com To: + 16135551234@VM1.mycompany.com From: 「パーソンズ、グレン、「 <12145551234@VM2.mycompany.com 、gt;、日付:、」 月曜日、1993年8月26日10:20:20 -0700(CDT)のMIMEバージョン: 1.0(声2.0)文書内容: 複合/音声メール。 バージョンは2.0と等しいです。 境界は"MessageBoundary"満足している転送コード化と等しいです: 7はMessage IDに噛み付きました: 123456789@VM2.mycompany.com 感度: 個人的な重要性: 高値
Vaudreuil & Parsons Standards Track [Page 43] RFC 3801 VPIMv2 June 2004
ボードルイと教区牧師標準化過程[43ページ]RFC3801VPIMv2 June 2004
--MessageBoundary Content-type: Audio/32KADPCM Content-Transfer-Encoding: Base64 Content-Disposition: inline; voice=Originator-Spoken-Name Content-Language: en-US Content-ID: part1@VM2-4321
--MessageBoundary文書内容: 32KADPCMの満足している転送オーディオ/コード化: Base64の満足している気質: インライン。 声は創始者によって話された名前の満足している言語と等しいです: アン米国コンテントID: part1@VM2-4321
glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd (This is a sample of the base-64 Spoken Name data) fgdhgddlkgpokpeowrit09==
glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd(これはベース-64のSpoken Nameデータのサンプルである)fgdhgddlkgpokpeowrit09=
--MessageBoundary Content-type: Audio/32KADPCM Content-Transfer-Encoding: Base64 Content-Disposition: inline; voice=Spoken-Subject Content-Language: en-US Content-ID: part2@VM2-4321
--MessageBoundary文書内容: 32KADPCMの満足している転送オーディオ/コード化: Base64の満足している気質: インライン。 声は話された対象の満足している言語と等しいです: アン米国コンテントID: part2@VM2-4321
glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd (This is a sample of the base-64 Spoken Subject data) fgdhgddlkgpokpeowrit09==
glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd(これはベース-64のSpoken Subjectデータのサンプルである)fgdhgddlkgpokpeowrit09=
--MessageBoundary Content-type: Audio/32KADPCM Content-Transfer-Encoding: Base64 Content-Description: Brand X Voice Message Content-Disposition: inline; voice=Voice-Message; filename=msg1.726 Content-Duration: 25
--MessageBoundary文書内容: 32KADPCMの満足している転送オーディオ/コード化: Base64の満足している記述: Xに音声メールの満足している気質と商標を付けてください: インライン。 声は音声メールと等しいです。 ファイル名はmsg1.726 Content-持続時間と等しいです: 25
iIiIiIjMzN3czdze3s7d7fwfHhcvESJVe/4yEhLz8/FOQjVFRERCESL/zqrq (This is a sample of the base64 message data) zb8tFdLTQt1PXj u7wjOyRhws+krdns7Rju0t4tLF7cE0K0MxOTOnRW/Pn30c8uHi9==
iIiIiIjMzN3czdze3s7d7fwfHhcvESJVe/4yEhLz8/FOQjVFRERCESL/zqrq(これはbase64メッセージデータのサンプルである)zb8tFdLTQt1PXj u7wjOyRhws+krdns7Rju0t4tLF7cE0K0MxOTOnRW/Pn30c8uHi9=
--MessageBoundary- - - -
--MessageBoundary--、--、-
The following message is a forwarded single segment voice. Both the forwarded message and the forwarding message contain the senders spoken names.
以下のメッセージは進められたただ一つのセグメント声です。 転送されたメッセージと推進メッセージの両方が送付者を含みます。名前を話します。
To: +12145551212@vm1.mycompany.com
From: "Vaudreuil, Greg" <+19725552345@VM2.mycompany.com>
Date: Mon, 26 Aug 93 10:20:20 -0700 (CDT)
MIME-Version: 1.0 (Voice 2.0)
Content-type: Multipart/Voice-Message; Version=2.0;
Boundary="MessageBoundary"
Content-Transfer-Encoding: 7bit
Message-ID: ABCD-123456789@VM2.mycompany.com
To: + 12145551212@vm1.mycompany.com From: 「ボードルイ、グレッグ」<+ 19725552345@VM2.mycompany.com 、gt;、日付: 月曜日、1993年8月26日10:20:20 -0700(CDT)のMIMEバージョン: 1.0(声2.0)文書内容: 複合/音声メール。 バージョンは2.0と等しいです。 境界は"MessageBoundary"満足している転送コード化と等しいです: 7はMessage IDに噛み付きました: ABCD-123456789@VM2.mycompany.com
Vaudreuil & Parsons Standards Track [Page 44] RFC 3801 VPIMv2 June 2004
ボードルイと教区牧師標準化過程[44ページ]RFC3801VPIMv2 June 2004
--MessageBoundary
Content-type: Audio/32KADPCM
Content-Transfer-Encoding: Base64
Content-Disposition: inline; voice=Originator-Spoken-Name
Content-Language: en-US
Content-ID: part3@VM2-4321
--MessageBoundary文書内容: 32KADPCMの満足している転送オーディオ/コード化: Base64の満足している気質: インライン。 声は創始者によって話された名前の満足している言語と等しいです: アン米国コンテントID: part3@VM2-4321
glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd
(This is a sample of the base-64 Spoken Name data)
fgdhgd dlkgpokpeowrit09==
glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd(これはベース-64のSpoken Nameデータのサンプルである)fgdhgd dlkgpokpeowrit09=
--MessageBoundary
Content-type: Audio/32KADPCM
Content-Description: Forwarded Message Annotation
Content-Disposition: inline; voice=Voice-Message
Content-Transfer-Encoding: Base64
--MessageBoundary文書内容: 32KADPCMの満足しているオーディオ/記述: 進められたメッセージ注釈満足している気質: インライン。 声は音声メールの満足している転送コード化と等しいです: Base64
glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd
(This is the voiced introductory remarks encoded in base64)
jrgoij3o45itj09fiuvdkjgWlakgQ93ijkpokfpgokQ90gQ5tkjpokfgW
dlkgpokpeowrit09==
glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd(これはbase64でコード化された有声な前置きである)jrgoij3o45itj09fiuvdkjgWlakgQ93ijkpokfpgokQ90gQ5tkjpokfgW dlkgpokpeowrit09=
Vaudreuil & Parsons Standards Track [Page 45] RFC 3801 VPIMv2 June 2004
ボードルイと教区牧師標準化過程[45ページ]RFC3801VPIMv2 June 2004
--MessageBoundary
Content-type: Message/RFC822
Content-Transfer-Encoding: 7bit
--MessageBoundary文書内容: RFC822の満足している転送メッセージ/コード化: 7ビット
To: +19725552345@VM2.mycompany.com
From: "Parsons, Glenn, W." <+16135551234@VM1.mycompany.com>
Date: Mon, 26 Aug 93 8:23:10 -0500 (EST)
Content-type: Multipart/Voice-Message; Version=2.0;
Boundary="MessageBoundary2"
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0 (Voice 2.0)
To: + 19725552345@VM2.mycompany.com From: 「」 パーソンズ、グレン、W.<+ 16135551234@VM1.mycompany.com 、gt;、日付: 月曜日、1993年8月26日8:23:10 -0500(米国東部標準時の)の文書内容: 複合/音声メール。 バージョンは2.0と等しいです。 境界=、「MessageBoundary2"の満足している転送コード化:」 7はMIMEバージョンに噛み付きました: 1.0 (声2.0)
--MessageBoundary2
Content-type: Audio/32KADPCM
Content-Transfer-Encoding: Base64
Content-Disposition: inline; voice=Originator-Spoken-Name
Content-Language: en-US
Content-ID: part6@VM2-4321
--MessageBoundary2文書内容: 32KADPCMの満足している転送オーディオ/コード化: Base64の満足している気質: インライン。 声は創始者によって話された名前の満足している言語と等しいです: アン米国コンテントID: part6@VM2-4321
glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd
(This is a sample of the base-64 Spoken Name data) fgdhgd
dlkgpokpeowrit09==
glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd(これはベース-64のSpoken Nameデータのサンプルである)fgdhgd dlkgpokpeowrit09=
--MessageBoundary2
Content-type: Audio/32KADPCM
Content-Disposition: inline; voice=Voice-Message
Content-Transfer-Encoding: Base64
--MessageBoundary2文書内容: 32KADPCMの満足しているオーディオ/気質: インライン。 声は音声メールの満足している転送コード化と等しいです: Base64
glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd
(This is the original message audio data) fgwersdfmniwrjj
jrgoij3o45itj09fiuvdkjgWlakgQ93ijkpokfpgokQ90gQ5tkjpokfgW
dlkgpokpeowrit09==
glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd(これはメッセージのオリジナルのオーディオデータである)fgwersdfmniwrjj jrgoij3o45itj09fiuvdkjgWlakgQ93ijkpokfpgokQ90gQ5tkjpokfgW dlkgpokpeowrit09=
--MessageBoundary2--
--MessageBoundary2--
--MessageBoundary--
--MessageBoundary--
Vaudreuil & Parsons Standards Track [Page 46] RFC 3801 VPIMv2 June 2004
ボードルイと教区牧師標準化過程[46ページ]RFC3801VPIMv2 June 2004
The following example is for a DSN sent to the sender of a message by a VPIM gateway at VM1.company.com for a mailbox which does not exist.
以下の例はVPIMゲートウェイによってメッセージの送付者に送られたDSNのために存在しないメールボックスのためのVM1.company.comにあります。
Date: Thu, 7 Jul 1994 17:16:05 -0400
From: Mail Delivery Subsystem <MAILER-DAEMON@vm.company.com>
Message-ID: <199407072116.RAA14128@vm1.company.com>
Subject: Returned voice message
To: 2175552345@VM2.mycompany.com
MIME-Version: 1.0
Content-Type: multipart/report; report-type=delivery-status;
boundary="RAA14128.773615765/VM1.COMPANY.COM"
日付: 木曜日、1994年7月7日の17:16:05 -0400From: 配送 Subsystem <MAILER-DAEMON@vm.company.com に郵送してください、gt;、Message ID: <199407072116.RAA14128@vm1.company.com>Subject: 返された音声メールTo: 2175552345@VM2.mycompany.com MIMEバージョン: 1.0コンテントタイプ: 複合/レポート。 レポートタイプは配送状態と等しいです。 境界="RAA14128.773615765/VM1.COMPANY.COM"
--RAA14128.773615765/VM1.COMPANY.COM
Content-type: Audio/32KADPCM
Content-Description: Spoken Delivery Status Notification
Content-Disposition: inline; voice= Voice-Message-Notification
Content-Transfer-Encoding: Base64
--RAA14128.773615765/VM1.COMPANY.COM文書内容: 32KADPCMの満足しているオーディオ/記述: 話された配送状態通知満足している気質: インライン。 声は声のメッセージ通知Content転送コード化と等しいです: Base64
glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadadffsssddasdasd
(This is a voiced description of the error in base64)
jrgoij3o45itj09fiuvdkjgWlakgQ93ijkpokfpgokQ90gdffkjpokfgW
dlkgpokpeowrit09==
glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadadffsssddasdasd(これはbase64の誤りの有声な記述である)jrgoij3o45itj09fiuvdkjgWlakgQ93ijkpokfpgokQ90gdffkjpokfgW dlkgpokpeowrit09=
--RAA14128.773615765/VM1.COMPANY.COM
Content-type: Message/Delivery-Status
--RAA14128.773615765/VM1.COMPANY.COM文書内容: 配送メッセージ/状態
Reporting-MTA: dns; vm1.company.com
報告しているMTA: dns。 vm1.company.com
Original-Recipient: rfc822; 2145551234@VM1.mycompany.com
Final-Recipient: rfc822; 2145551234@VM1.mycompany.com
Action: failed
Status: 5.1.1 (User does not exist)
Diagnostic-Code: smtp; 550 Mailbox not found
Last-Attempt-Date: Thu, 7 Jul 1994 17:15:49 -0400
オリジナルの受取人: rfc822。 2145551234@VM1.mycompany.com 最終受理者: rfc822。 2145551234@VM1.mycompany.com 動作: 失敗したStatus: 5.1.1 (ユーザは存在しません)診断コード: smtp。 Lastが日付:を試みるのが見つけられなかった550メールボックス 木曜日、1994年7月7日17:15:49 -0400
Vaudreuil & Parsons Standards Track [Page 47] RFC 3801 VPIMv2 June 2004
ボードルイと教区牧師標準化過程[47ページ]RFC3801VPIMv2 June 2004
--RAA14128.773615765/VM1.COMPANY.COM
content-type: Message/RFC822
--RAA14128.773615765/VM1.COMPANY.COMの満足しているタイプ: メッセージ/RFC822
[original VPIM message goes here]
[オリジナルのVPIMメッセージはここに行きます]
--RAA14128.773615765/VM1.COMPANY.COM--
--RAA14128.773615765/VM1.COMPANY.COM--
The following example is for an MDN sent to the original sender for a message that has been played. This delivered VPIM message was received by a corporate gateway and relayed to a unified mailbox.
以下の例はプレーされたメッセージのための元の送り主に送られたMDNのためのものです。 この渡されたVPIMメッセージは、法人のゲートウェイによって受け取られて、統一されたメールボックスにリレーされました。
Date: Thu, 7 Jul 1994 17:16:05 -0400
From: "Greg Vaudreuil" <22722@vm.company.com>
Message-ID: <199407072116.RAA14128@exchange.company.com>
Subject: Voice message played
To: 2175552345@VM2.mycompany.com
MIME-Version: 1.0
Content-Type: multipart/report;
Report-type=disposition-notification;
Boundary="RAA14128.773615765/EXCHANGE.COMPANY.COM"
日付: 木曜日、1994年7月7日の17:16:05 -0400From: 「グレッグ・ボードルイ、「 <22722@vm.company.com 、gt;、Message ID:、」 <199407072116.RAA14128@exchange.company.com>Subject: 音声メールはTo:をプレーしました。 2175552345@VM2.mycompany.com MIMEバージョン: 1.0コンテントタイプ: 複合/レポート。 レポートタイプは気質通知と等しいです。 境界="RAA14128.773615765/EXCHANGE.COMPANY.COM"
--RAA14128.773615765/EXCHANGE.COMPANY.COM Content-type: Audio/32KADPCM Content-Description: Spoken Disposition Notification Content-Disposition: inline; voice= Voice-Message-Notification Content-Transfer-Encoding: Base64
--RAA14128.773615765/EXCHANGE.COMPANY.COM文書内容: 32KADPCMの満足しているオーディオ/記述: 話された気質通知満足している気質: インライン。 声は声のメッセージ通知Content転送コード化と等しいです: Base64
glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadadffsssddasdasd (Voiced description of the disposition action in base64) jrgoij3o45itj09fiuvdkjgWlakgQ93ijkpokfpgokQ90gdffkjpokfgW dlkgpokpeowrit09==
glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadadffsssddasdasd(base64の気質動作の記述を声に出す)jrgoij3o45itj09fiuvdkjgWlakgQ93ijkpokfpgokQ90gdffkjpokfgW dlkgpokpeowrit09=
--RAA14128.773615765/EXCHANGE.COMPANY.COM Content-type: Message/Disposition-Notification
--RAA14128.773615765/EXCHANGE.COMPANY.COM文書内容: 気質メッセージ/通知
Reporting-UA: gregs-laptop.dallas.company.com (Unified FooMail 3.0)
報告しているUA: gregs-laptop.dallas.company.com(統一されたFooMail3.0)
Original-Recipient: rfc822;22722@vm.company.com Final-Recipient: rfc822;Greg.Vaudreuil@foomail.company.com Original-Message-ID: <199509192301.12345@vm2.mycompany.com> Disposition: manual-action/MDN-sent-automatically; displayed
オリジナルの受取人: rfc822;22722@vm.company.com 最終受理者: rfc822;Greg.Vaudreuil@foomail.company.com の元のMessage ID: <199509192301.12345@vm2.mycompany.com>気質: MDNは自動的に手動の動き/発信していました。 表示します。
--RAA14128.773615765/EXCHANGE.COMPANY.COM Content-type: Message/RFC822
--RAA14128.773615765/EXCHANGE.COMPANY.COM文書内容: メッセージ/RFC822
[original VPIM message goes here]
[オリジナルのVPIMメッセージはここに行きます]
--RAA14128.773615765/EXCHANGE.COMPANY.COM--
--RAA14128.773615765/EXCHANGE.COMPANY.COM--
Vaudreuil & Parsons Standards Track [Page 48] RFC 3801 VPIMv2 June 2004
ボードルイと教区牧師標準化過程[48ページ]RFC3801VPIMv2 June 2004
14. Appendix C - Example Error Voice Processing Error Codes
14. 付録C--例の誤り音声処理エラーコード
The following common voice processing errors and their corresponding status codes are given as examples. The text after the error codes is intended only for reference to describe the error code. Implementations should provide implementation-specific informative comments after the error code rather than the text below.
例として以下の一般的な声の整理過程の誤差とそれらの対応するステータスコードを与えます。 エラーコードの後のテキストは参照が単にエラーコードについて説明することを意図します。 実現は以下のテキストよりむしろエラーコードの後に実現特有の有益なコメントを提供するべきです。
Error condition RFC 1893 Error codes
----------------------------- --------------------------------
RFC1893Errorがコード化するエラー条件----------------------------- --------------------------------
Analog delivery failed 4.4.1 Persistent connection error
because remote system is busy - busy
リモートシステムが忙しいので、アナログの配送は4.4.1Persistent接続誤りに失敗しました--、忙しさ
Analog delivery failed 4.4.1 Persistent protocol error
because remote system is - no answer from host
ring-no-answer
リモートシステムが失敗したので、アナログの配送は4.4.1Persistentプロトコル誤りに失敗しました--いいえはホストから答えを全く鳴らさなかった状態で答えます。
Remote system did not answer 5.5.5 Permanent protocol error
AMIS-Analog handshake ("D" in - wrong version
response to "C" at connect
time)
リモートシステムは5.5.5Permanentプロトコル誤りエイミス-アナログ握手に答えませんでした。(中の「D」--接続時間の「C」への間違ったバージョン応答)
Mailbox does not exist 5.1.1 Permanent mailbox error
- does not exist
メールボックスが存在していない、5.1 .1 Permanentメールボックス誤り--、存在していません。
Mailbox full or over quota 4.2.2 Persistent mailbox error
- full
いっぱいか割当て4.2.2Persistentメールボックス誤りの上のメールボックス--いっぱいに
Disk full 4.3.1 Persistent system error
- full
ディスク完全な4.3.1Persistentシステム・エラー--いっぱいに
Command out of sequence 5.5.1 Permanent protocol error
- invalid command
系列5.5.1Permanentプロトコル誤りからのコマンド--無効のコマンド
Frame Error 5.5.2 Permanent protocol error
- syntax error
フレームError5.5.2Permanentプロトコル誤り--構文エラー
Mailbox does not support FAX 5.6.1 Permanent media error
- not supported
メールボックスはFAX5.6.1Permanentメディア誤りを支持しません--支持されません。
Mailbox does not support TEXT 5.6.1 Permanent media error
- not supported
メールボックスはTEXT5.6.1Permanentメディア誤りを支持しません--支持されません。
Sender is not authorized 5.7.1 Permanent security error
- sender not authorized
送付者は認可された5.7.1Permanentセキュリティ誤りではありません--、送付者は認可しませんでした。
Vaudreuil & Parsons Standards Track [Page 49] RFC 3801 VPIMv2 June 2004
ボードルイと教区牧師標準化過程[49ページ]RFC3801VPIMv2 June 2004
Message marked private, but 5.3.3 Permanent system error
system is not private capable - not feature capable
できる兵卒ではなく、著しい個人的であるのにもかかわらずの、5.3.3Permanentシステム・エラーシステムがあるというメッセージ--できる特徴でない
15. Appendix D - Example Voice Processing Disposition Types
15. 付録D--例の音声処理気質タイプ
The following common voice processing disposition conditions and their corresponding MDN Disposition (which contains the disposition mode, type and modifier, if applicable) are given as examples. Implementers should refer to [MDN] for a full description of the format of message disposition notifications.
例として以下の一般的な音声処理気質条件とそれらの対応するMDN Disposition(適切であるなら、気質モード、タイプ、および修飾語を含む)を与えます。 Implementersはメッセージ気質通知の形式の余すところのない解説について[MDN]について言及するはずです。
Notification event MDN Disposition mode, type & modifier ------------------------------ ------------------------------------
通知イベントMDN Dispositionモード、タイプ、および修飾語------------------------------ ------------------------------------
Message played by recipient, manual-action/MDN-sent-automatically; receipt automatically returned displayed
メッセージは受取人、自動的に送られた手動の動き/MDNでプレーしました。 自動的に返された領収書は表示しました。
Message deleted from mailbox manual-action/MDN-sent-automatically; by user without listening deleted
メッセージはメールボックスから自動的に送られた手動の動き/MDNを削除しました。 削除された聴取のないユーザで
Message cleared when mailbox manual-action/MDN-sent-automatically; deleted by admin deleted/mailbox-terminated
MDNが自動的にメールボックスの手動の動き/発信していたとき、メッセージはクリアされました。 アドミンで、削除されるかメールボックスによって終えられた状態で、削除されます。
Message automatically deleted automatic-action/ when older than administrator MDN-sent-automatically; deleted/ set threshold expired
自動的に送られた管理者MDNより古いときに、メッセージは自動的に自動動作/を削除しました。 敷居満期で削除されるか、または設定されます。
Message processed, however manual-action/MDN-sent-automatically; audio encoding unknown - processed/error unable to play to user Error: unknown audio encoding
MDNが自動的にどんなに手動の動き/発信していたとしても、メッセージは処理されました。 未知をコード化するオーディオ--ユーザErrorに演奏できない処理/誤り: 未知のオーディオコード化
16. Appendix E - IANA Registrations
16. 付録E--IANA登録証明書
There are no changes to the registration per [DISP] of the voice content disposition parameter defined in the earlier VPIM V2 document, RFC 2421. There are no changes to the registration per [MIME4] of the Multipart/voice-message content type defines in the earlier VPIM v2 document, RFC 2423.
満足している気質パラメタが以前のVPIM V2ドキュメントで定義した声の[DISP]あたりの登録への変化が全くありません、RFC2421。 満足しているタイプが以前のVPIM v2ドキュメントで定義するMultipart/音声メールの[MIME4]あたりの登録への変化が全くありません、RFC2423。
Both are presented here for information.
両方が情報のためにここに提示されます。
Vaudreuil & Parsons Standards Track [Page 50] RFC 3801 VPIMv2 June 2004
ボードルイと教区牧師標準化過程[50ページ]RFC3801VPIMv2 June 2004
16.1. Voice Content-Disposition Parameter Definition
16.1. 声の満足している気質パラメタ定義
To: IANA@IANA.ORG
To: IANA@IANA.ORG
Subject: Registration of new Content-Disposition parameter
Subject: 新しいContent-気質パラメタの登録
Content-Disposition parameter name: voice
満足している気質パラメタ名: 声
Allowable values for this parameter:
このパラメタのための許容量:
Voice-Message - the primary voice message,
Voice-Message-Notification - a spoken delivery notification
or spoken disposition notification,
Originator-Spoken-Name - the spoken name of the originator,
Recipient-Spoken-Name - the spoken name of the recipient if
available to the originator and present if there is ONLY one
recipient,
Spoken-Subject- the spoken subject of the message, typically
spoken by the originator
声メッセージ--第一の音声メール、話された配送通知の、または、話されたVoiceメッセージ通知気質通知、Originator、話された名前、--創始者の話された名前、Recipient、話された名前、--、そこであるなら、受取人における名義の、しかし、創始者と現在に利用可能な話しは1人の受取人だけです、Spoken受けることがある-、創始者によって通常話されたメッセージの話された対象
Description:
記述:
In order to distinguish between the various types of audio contents in a VPIM voice message a new disposition parameter "voice" is defined with the preceding values to be used as appropriate. Note that there SHOULD only be one instance of each of these types of audio contents per message level. Additional instances of a given type (i.e., parameter value) may occur within an attached forwarded voice message.
「声」という新しい気質パラメタはVPIM音声メールの様々なタイプのオーディオコンテンツを見分けるために前の値で定義されて、適宜使用されます。 そこでそれに注意してください、SHOULD、単にそれぞれのこれらのタイプのメッセージレベルあたりのオーディオコンテンツの1つの例になってください。 与えられたタイプ(すなわち、パラメタ値)の追加例は添付の転送された音声メールの中に起こるかもしれません。
16.2. Multipart/Voice-Message MIME Media Type Definition
16.2. 複合の、または、メッセージを声に出しているMIMEメディア型定義
To: ietf-types@iana.org
Subject: Registration of MIME media type
Multipart/voice-message
To: ietf-types@iana.org Subject: MIMEメディアタイプMultipart/音声メールの登録
MIME media type name: multipart
MIMEメディア型名: 複合
MIME subtype name: voice-message
MIME「副-タイプ」は以下を命名します。 音声メール
Required parameters: boundary, version
必要なパラメタ: 境界、バージョン
The use of boundary is defined in [MIME2]
境界の使用は中で定義されます。[MIME2]
Vaudreuil & Parsons Standards Track [Page 51] RFC 3801 VPIMv2 June 2004
ボードルイと教区牧師標準化過程[51ページ]RFC3801VPIMv2 June 2004
The version parameter that contains the value "2.0" if
enclosed content conforms to [VPIM2R2]. The absence of this
parameter indicates conformance to the previous version
defined in RFC 1911 [VPIM1].
それは値を含んでいます。バージョンパラメタ、「同封されるなら、何2インチも、内容は[VPIM2R2]に従います」。 このパラメタの欠如はRFC1911[VPIM1]で定義された旧バージョンに順応を示します。
Optional parameters: none
任意のパラメタ: なし
Encoding considerations: 7bit, 8bit or Binary
問題をコード化します: 8の7ビット、ビットまたはバイナリー
Security considerations:
セキュリティ問題:
This definition identifies the content as being a voice
message. In some environments (though likely not the
majority), the loss of the anonymity of the content may be a
security issue.
この定義は音声メールであるとして内容を特定します。 いくつかの環境、(ありそうである、大部分でない)、内容の匿名の損失は安全保障問題であるかもしれません。
Interoperability considerations:
相互運用性問題:
Systems developed to conform with [VPIM1] may not conform to
this registration. Specifically, the required version will
likely be absent, in this case the recipient system should
still be able to accept the message and will be able to
handle the content. The VPIM v1 positional identification,
however, would likely be lost.
[VPIM1]に従うために開発されたシステムはこの登録に一致しないかもしれません。 明確に、必要なバージョンがおそらく欠けて、この場合、受取人システムは、まだメッセージを受け入れることができるべきであって、内容を扱うことができるでしょう。 しかしながら、VPIM v1の位置の識別はおそらく失われるでしょう。
Published specification:
This document
広められた仕様: このドキュメント
Applications that use this media type:
このメディアタイプを使用するアプリケーション:
Primarily voice messaging
主として声のメッセージング
Additional information:
追加情報:
Magic number(s): none
File extension(s): .VPM
Macintosh File Type Code(s): VPIM
マジックナンバー(s): なにも、File拡張子: .VPMマッキントッシュファイルタイプは(s)をコード化します: VPIM
Person & email address to contact for further information:
詳細のために連絡する人とEメールアドレス:
Glenn W. Parsons
gparsons@nortelnetworks.com
グレンW. gparsons@nortelnetworks.com 教区牧師
Gregory M. Vaudreuil
gregv@ieee.org
グレゴリーM.ボードルイ gregv@ieee.org
Intended usage: COMMON
意図している用法: 一般的
Vaudreuil & Parsons Standards Track [Page 52] RFC 3801 VPIMv2 June 2004
ボードルイと教区牧師標準化過程[52ページ]RFC3801VPIMv2 June 2004
Author/Change controller:
コントローラを書くか、または変えてください:
Glenn W. Parsons & Gregory M. Vaudreuil
グレン・W.パーソンズとグレゴリー・M.ボードルイ
17. Appendix F - Change History: RFC 2421 (VPIM V2) to this Document
17. 付録F--歴史を変えてください: このDocumentへのRFC2421(VPIM V2)
The updated profile in this document is based on the implementation and operational deployment experience of several vendors. The changes are categorized as general, content, transport and conformance. They are summarized below:
アップデートされたプロフィールは本書ではいくつかの業者の実現と操作上の展開経験に基づいています。 変化は一般的で、満足している輸送と順応として分類されます。 それらは以下へまとめられます:
1. General
1. 一般
- Various and substantial editorial updates to improve
readability.
- 読み易さを改良する様々でかなりの編集のアップデート。
- Separated send rules from receive rules to aid clarity.
- 分離、規則を送る、規則を受け取って、明快を支援してください。
- Clarified the behavior upon reception of unrecognized content
types expected with the interworking between voice and unified
messaging systems. (E.g., Unsupported non-audio contents should
be discarded to deliver the audio message.)
- 声とユニファイド・メッセージングシステムの間には、織り込むことがある状態で予想された認識されていない満足しているタイプのレセプションで振舞いをはっきりさせました。(例えばUnsupported非オーディオコンテンツはオーディオメッセージを送るために捨てられるべきです。)
- Reworked the sensitivity requirements to align them with X.400.
Eliminated dependencies upon the MIXER documents.
- X.400にそれらを一直線にするという感度要件を作りなおしました。 MIXERドキュメントで依存を根絶しました。
- Reorganized the content-type descriptions for clarity
- 明快のための満足している型記述を再編成します。
2. Content
2. 内容
- Changed handling of received lines by a gateway to SHOULD NOT
delete in a gateway. In gateways to systems such as AMIS, it is
not possible to preserve this information. It is intended that
such systems be able to claim conformance.
- SHOULD NOTへのゲートウェイのそばの容認された線の変えられた取り扱いはゲートウェイで削除します。 エイミスなどのシステムへのゲートウェイでは、この情報を保存するのは可能ではありません。 そのようなシステムが順応を要求できることを意図します。
- Eliminated the vCard as a supported VPIM V2 content type.
- 支持されたVPIM V2満足しているタイプとしてvCardを排除しました。
- Merged in text from RFC 2423 (Multipart/voice-message)
- RFC2423からのテキストでは、合併されています。(複合かメッセージを声に出します)です。
3. Transport
3. 輸送
- None
- なし
4. Conformance
4. 順応
- Aligned the table of Appendix A to the requirements in the text.
- Appendix Aのテーブルをテキストの要件に並べました。
Vaudreuil & Parsons Standards Track [Page 53] RFC 3801 VPIMv2 June 2004
ボードルイと教区牧師標準化過程[53ページ]RFC3801VPIMv2 June 2004
18. Authors' Addresses
18. 作者のアドレス
Gregory M. Vaudreuil Lucent Technologies 7291 Williamson Rd Dallas, TX 75214 United States
グレゴリーM.ボードルイルーセントテクノロジーズ7291ウィリアムソン・テキサス75214第ダラス(合衆国)
EMail: gregv@ieee.org
メール: gregv@ieee.org
Glenn W. Parsons Nortel Networks P.O. Box 3511, Station C Ottawa, ON K1Y 4H7 Canada
グレンW.ノーテル教区牧師は私書箱3511、駅のCオタワをK1Y 4H7カナダにネットワークでつなぎます。
Phone: +1-613-763-7582 Fax: +1-613-763-2697 EMail: GParsons@NortelNetworks.com
以下に電話をしてください。 +1-613-763-7582 Fax: +1-613-763-2697 メールしてください: GParsons@NortelNetworks.com
Vaudreuil & Parsons Standards Track [Page 54] RFC 3801 VPIMv2 June 2004
ボードルイと教区牧師標準化過程[54ページ]RFC3801VPIMv2 June 2004
19. Full Copyright Statement
19. 完全な著作権宣言文
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機能のための基金は現在、インターネット協会によって提供されます。
Vaudreuil & Parsons Standards Track [Page 55]
ボードルイと教区牧師標準化過程[55ページ]
一覧
スポンサーリンク
