RFC1911 日本語訳
1911 Voice Profile for Internet Mail. G. Vaudreuil. February 1996. (Format: TXT=50242 bytes) (Obsoleted by RFC2421, RFC2422, RFC2423) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group G. Vaudreuil Request for Comments: 1911 Octel Network Services Category: Experimental February 1996
コメントを求めるワーキンググループG.ボードルイの要求をネットワークでつないでください: 1911年のOctelネットワーク・サービスカテゴリ: 実験的な1996年2月
Voice Profile for Internet Mail
インターネットメールのための声のプロフィール
Status of this Memo
このMemoの状態
This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 このメモはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。
1. Abstract
1. 要約
A class of special-purpose computers has evolved to provide voice messaging services. These machines generally interface to a telephone switch and provide call answering and voice messaging services. Traditionally, messages sent to a non-local machine are transported using analog networking protocols based on DTMF signaling and analog voice playback. As the demand for networking increases, there is a need for a standard high-quality digital protocol to connect these machines. The following document is a profile of the Internet standard MIME and ESMTP protocols for use as a digital voice networking protocol.
専用計算機のクラスは、音声メッセージングサービスを提供するために発展しました。 これらのマシンは、一般に、電話スイッチに接続して、呼び出し回答と音声メッセージングサービスを供給します。 伝統的に、非地方のマシンに送られたメッセージは、DTMFシグナリングとアナログの声の再生に基づくアナログのネットワーク・プロトコルを使用することで輸送されます。 ネットワークの需要が増加するのに従って、標準の高品質なデジタルプロトコルがこれらのマシンを接続する必要があります。 以下のドキュメントはデジタル声のネットワーク・プロトコルとしての使用のためのインターネット標準MIMEとESMTPプロトコルのプロフィールです。
This profile is based on an earlier effort in the Audio Message Interchange Specification (AMIS) group to define a voice messaging protocol based on X.400 technology. This protocol is intended to satisfy the user requirements statement from that earlier work with the industry standard ESMTP/MIME mail protocol infrastructures already used within corporate internets. This profile will be called the voice profile in this document.
このプロフィールは、X.400技術に基づく声のメッセージング・プロトコルを定義するためにAudio Message Interchange Specification(エイミス)グループで以前の取り組みに基づいています。 このプロトコルがその以前の仕事から法人のインターネットの中で既に使用される業界基準ESMTP/MIMEメールプロトコルインフラストラクチャにユーザ要件声明を満たすことを意図します。 このプロフィールは本書では声のプロフィールと呼ばれるでしょう。
2. Scope and Design Goals
2. 範囲とデザイン目標
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 including voice and facsimile.
MIMEは多目的のインターネットマルチメディアメッセージング規格です。 このドキュメントは、声とファクシミリを含む様々なメッセージング技術の交換に明らかに能力を認識して、メカニズムを提供します。
This document specifies a profile of the TCP/IP multimedia messaging protocols for use by special-purpose voice processing platforms. These platforms have historically been special-purpose computers and often do not have facilities normally associated with a traditional Internet Email-capable computer. This profile is intended to specify the minimum common set of features and functionally for conformant
このドキュメントは専用音声処理プラットホームのそばでTCP/IPマルチメディアメッセージング・プロトコルのプロフィールを使用に指定します。これらのプラットホームは、歴史的に専用計算機であり、しばしば通常、伝統的なインターネットメールできるコンピュータに関連している施設を持っているというわけではありません。 このプロフィールが最小の一般的なセットの特徴をconformantに機能上指定することを意図します。
Vaudreuil Experimental [Page 1] RFC 1911 MIME Voice Profile February 1996
ボードルイの実験的な[1ページ]RFC1911は声のプロフィール1996年2月にまねます。
systems.
システム。
The voice profile does not place limits on the use of additional media types or protocol options. However, systems which are conformant to this profile should not send messages with features beyond this profile unless explicit per-destination configuration of these enhanced features is provided. Such configuration information could be stored in a directory, though the implementation of this is a local matter.
声のプロフィールは追加メディアタイプかプロトコルオプションの使用に限界を置きません。 しかしながら、これらの拡張機能の1目的地あたりの明白な構成が提供されない場合、特徴がこのプロフィールを超えてある状態で、このプロフィールへのconformantであるシステムはメッセージを送るはずがありません。 この実装は地域にかかわる事柄ですが、ディレクトリにそのような設定情報を保存できました。
The following are typical limitations of voice messaging platform which were considered in creating this baseline profile.
↓これはこの基線プロフィールを作成する際に考えられた声のメッセージングプラットホームの典型的な制限です。
1) Text messages are not normally received and often cannot be
displayed or viewed. They can often be processed only via
advanced text-to-speech or text-to-fax features not currently
present in these machines.
1) しばしばテキスト・メッセージを通常、受け取らないで、表示するというわけではありませんし、また見ることができるというわけではありません。 特徴が現在これらのマシンに提示しないテキストから高度なテキストからスピーチか単にファックスでそれらをしばしば処理できます。
2) Voice mail machines usually act as an integrated Message
Transfer Agent and a User Agent. The voice mail machine is
responsible for final delivery, and there is no relaying of
messages. RFC 822 header fields may have limited use in the
context of the simple messaging features currently deployed.
2) 通常、ボイスメールマシンは統合Message TransferエージェントとUserエージェントとして務めます。 ボイスメールマシンは最終的な配送に原因となります、そして、メッセージについてリレーしてはいけません。 RFC822ヘッダーフィールドは現在配布されている簡単なメッセージング機能の文脈における使用を制限したかもしれません。
3) VM message stores are generally not capable of preserving the
full semantics of an Internet message. As such, use of a voice
mail machine for general message forwarding and gatewaying is not
supported. Storage of "Received" lines and "Message-ID" may be
limited.
3) 一般に、VMメッセージ店はインターネットメッセージの完全な意味論を保存できません。 そういうものとして、ボイスメールマシンの一般的なメッセージ推進とgatewayingの使用はサポートされません。 「受け取った」ストレージは立ち並んでいます、そして、「Message ID」は制限されるかもしれません。
4) Nothing in this document precludes use of a general purpose
email gateway from providing these services. However, significant
performance degradation may result if the email gateway does not
support the ESMTP options recommended by this document.
4) 何も、これらのサービスを提供するので、本書では汎用のメールゲートウェイの使用を排除しません。 しかしながら、メールゲートウェイがこのドキュメントによって推薦されたESMTPオプションをサポートしないなら、重要な性能退行は結果として生じるかもしれません。
5) Internet-style mailing lists are not generally supported.
Distribution lists are implemented as local alias lists.
5) 一般に、インターネットスタイルメーリングリストはサポートされません。 発送先リストはローカルの別名リストとして実装されます。
6) There is generally no human operator. Error reports must be
machine-parsable so that helpful responses can be given to users
whose only access mechanism is a telephone.
6) 一般に、どんな人間のオペレータもいません。 エラー・レポートは、唯一のアクセス機構が電話であるユーザに役立っている応答を与えることができるくらいマシン「パー-可能」でなければなりません。
7) The system user names are often limited to 16 or fewer numeric
characters. Alpha characters are not generally used for mailbox
identification as they cannot be easily entered from a telephone
terminal.
7) システムユーザ名はしばしば16か、より少ない数字に制限されます。 一般に、アルファキャラクタはメールボックス識別に電話端末から彼らに容易に入ることができないように使用されません。
Vaudreuil Experimental [Page 2] RFC 1911 MIME Voice Profile February 1996
ボードルイの実験的な[2ページ]RFC1911は声のプロフィール1996年2月にまねます。
It is a goal of this effort to make as few restrictions and additions to the existing Internet mail protocols as possible while satisfying the user requirements for interoperability with current 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 is outside the scope of this document.
この仕様はTCP/IPネットワークにおける使用のために意図して、しかしながら、他のトランスポート・プロトコルの上でSMTPプロトコル群を使用するのは可能です。 このドキュメントの範囲の外にそのようなもののためのパラメタが使用する必要なプロトコルがあります。
This profile is intended to be robust enough to be used in an environment such as the global Internet with installed base gateways which do not understand MIME. It is expected that a messaging system will be managed by a system administrator who can perform TCP/IP network configuration. When using facsimile or multiple voice encodings, it is expected that the system administrator will 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 this directory listing capabilities is a local matter.
MIMEを理解していないインストールされたベースゲートウェイがある世界的なインターネットなどの環境で使用されるためにこのプロフィールが十分強健であることを意図します。 メッセージシステムがTCP/IPネットワーク・コンフィギュレーションを実行できるシステム管理者によって管理されると予想されます。 ファクシミリか複数の声のencodingsを使用するとき、システム管理者がネットワークでつながれたメールマシンが特徴サポートの不足のため「非-提出物」メッセージの発信を減少させる能力のリストを維持すると予想されます。 能力を記載するこのディレクトリの構成、実装、および管理は地域にかかわる事柄です。
This specification is a profile of the relevant TCP/IP Internet protocols. These technologies, as well as the specifications for the Internet mail protocols, are defined in the Request for Comment (RFC) document series. That series documents the standards as well as the lore of the TCP/IP protocol suite. This document should be read with the following RFC documents: RFC 821, Simple Mail Transfer Protocol; RFC 822, Standard for the format of ARPA Internet Messages; RFC 1521 and RFC 1522, Multipurpose Internet Mail Extensions; RFC 1651, RFC 1652, and RFC 1653, SMTP Service Extensions (ESMTP); and RFC 1034 and RFC 1035, Domain Name System. Where additional functionality is needed, it will be defined in this document or in an appendix.
この仕様は関連TCP/IPインターネットプロトコルのプロフィールです。 これらの技術、およびインターネットメールプロトコルのための仕様はComment(RFC)ドキュメントシリーズのためにRequestで定義されます。 そのシリーズはTCP/IPプロトコル群に関する口碑と同様に規格を記録します。 このドキュメントは以下のRFCドキュメントで読まれるべきです: RFC821、簡単なメール転送プロトコル。 RFC822、ARPAインターネットMessagesの形式のためのStandard。 RFC1521とRFC1522、マルチパーパスインターネットメールエクステンション。 RFC1651、RFC1652、およびRFC1653、SMTPは拡大(ESMTP)を修理します。 RFC1034とRFC1035、ドメインネームシステム。 追加機能性が必要であるところでは、それはこのドキュメントか付録で定義されるでしょう。
3. Protocol Restrictions
3. プロトコル制限
This protocol does not limit the number of recipients per message. Where possible, 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. However, ESMTP currently does not provide a mechanism for indicating the number of supported recipients.
このプロトコルは1メッセージあたりの受取人の数を制限しません。 可能であるところでは、実装がただ一つのメッセージの受取人の数を制限するべきではありません。 どんな実装も無制限な受取人をサポートしないで、サポートしている受取人の数がかなり下位であるかもしれないと認められます。 しかしながら、ESMTPは現在、サポートしている受取人の数を示すのにメカニズムを提供しません。
Vaudreuil Experimental [Page 3] RFC 1911 MIME Voice Profile February 1996
ボードルイの実験的な[3ページ]RFC1911は声のプロフィール1996年2月にまねます。
This protocol does not limit the maximum message length. Implementors should understand that some machines will be unable to accept excessively long messages. A mechanism is defined in the RFC 1425 ESMTP extensions to declare the maximum message size supported.
このプロトコルは最大のメッセージ長を制限しません。 作成者は、いくつかのマシンが過度に長いメッセージを受け入れることができないのを理解するべきです。 メカニズムは、サイズがサポートした最大のメッセージを宣言するためにRFC1425ESMTP拡張子で定義されます。
The message size indicated in the ESMTP SIZE command is in bytes, not minutes. The number of bytes varies by voice encoding format and must include the MIME wrapper overhead. If the length must be known before sending, an approximate translation into minutes can be performed if the voice encoding is known.
ESMTP SIZEコマンドで示されたメッセージサイズが数分ではなく、バイトであります。 バイト数は、声のコード化形式で異なって、MIMEラッパーオーバーヘッドを含まなければなりません。 発信する前に長さを知っていなければならないなら、声のコード化が知られているなら、数分への大体の翻訳を実行できます。
4. Voice Message Interexchange Format
4. 音声メールInterexchange形式
The voice message interchange format is a profile of the Internet Email Protocol Suite. It requires components from the message format standard for Internet messages [RFC822], the Multipurpose Internet Message Extensions [MIME], the X.400 gateway specification [X.400], and the delivery report specifications [DRPT][STATUS].
音声メール置き換え形式はインターネットメールプロトコルSuiteのプロフィールです。 それはインターネットメッセージ[RFC822]、MultipurposeインターネットMessage Extensions[MIME]、X.400ゲートウェイ仕様[X.400]、および配送レポート仕様[DRPT][STATUS]のメッセージ・フォーマット規格からコンポーネントを必要とします。
4.1 Message Addressing Formats
4.1 メッセージアドレス指定形式
The RFC 822 uses 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.
RFC822はドメイン名システムを使用します。 この命名システムには、2つのコンポーネントがあります: ユーザ名かメールボックス識別に使用される地方の部分。 そして、グローバルなマシン識別に使用されるホスト部分。
The local part of the address shall be an ASCII string uniquely identifying a mailbox on a destination system. For voice messaging, the local part is a printable string containing the mailbox ID of the originator or recipient. Administration of this space is expected to conform to national or corporate private telephone numbering plans. While alpha characters and long mailbox identifiers are permitted, most voice mail networks rely on numeric mailbox identifiers to retain compatibility with the limited 10 digit telephone keypad.
アドレスの地方の部分は目的地システムの上で唯一メールボックスを特定するASCIIストリングになるでしょう。 声のメッセージングに関しては、地方の部分は創始者か受取人のメールボックスIDを含む印刷可能なストリングです。 このスペースの政権が国家の、または、法人の私設電話機付番プランに従うと予想されます。 アルファキャラクタと長いメールボックス識別子が受入れられている間、ほとんどのボイスメールネットワークが、限られた10ケタ電話キーパッドとの互換性を保有するために数値メールボックス識別子を当てにします。
For example, a compliant message may contain the address 2145551212@mycompany.com. It should be noted that while the example mailbox address is based on the North American Numbering Plan, any other corporate numbering plan can be used. The use of the domain naming 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. The mapping of dialed address to final destination system is generally accomplished through implementation-specific means.
例えば、対応するメッセージはアドレス 2145551212@mycompany.com を含むかもしれません。 例のメールボックスアドレスが北米のNumbering Planに基づいている間いかなる他の法人の付番プランも使用できることに注意されるべきです。 ユーザにとって、ドメイン命名システムの使用はわかりやすいはずです。 それは完全に適切なドメイン名(FQDN)がユーザによって入れられたアドレスに基礎づけたルックアップへのボイスメールマシンの責任です。 一般に、最終的な目的地システムへのダイヤルされたアドレスに関するマッピングは実装特有の手段で達成されます。
Special addresses are provided for compatibility with the conventions of the Internet mail system and to facilitate testing. These addresses do not use numeric local addresses, both to conform to
インターネット・メールシステムのコンベンションとの互換性、テストするのを容易にするために特別なアドレスを提供します。 これらのアドレスは数値ローカルにアドレス、従う両方を使用しません。
Vaudreuil Experimental [Page 4] RFC 1911 MIME Voice Profile February 1996
ボードルイの実験的な[4ページ]RFC1911は声のプロフィール1996年2月にまねます。
current Internet practice and to avoid conflict with existing numeric addressing plans. Some special addresses are as follows:
現在のインターネットは練習されます、そして、存在するとの闘争を避けるために、数値アドレシングは計画されています。 いくつかの特別なアドレスは以下の通りです:
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 a individual implementation choice.
コンベンションで、「郵便局長」という特別なメールボックスはすべてのシステムの上に存在しなければなりません。このアドレスは、病気の特徴に使用されて、定期的にシステム・マネージャによってチェックされるべきです。 このメールボックスは特にテキスト・メッセージを受け取りそうです(音声処理プラットホームで正常ではありません)。 これらのメッセージの特定の取り扱いは個々の実装選択です。
Loopback@domain
Loopback@domain
A special mailbox name named "loopback" SHOULD be designated for loopback testing. If supported, all messages sent to this mailbox MUST be returned back to the address listed in the From: address as a new message. The originating address of the returned address MUST be "postmaster" to prevent mail loops.
特別なメールボックス名は「ループバック」をSHOULDと命名しました。ループバックのために、テストしながら、指定されます。 サポートするなら、このメールボックスに送られたすべてのメッセージをFrom:に記載されたアドレスに返して戻さなければなりません。 新しいメッセージとしてのアドレス。 返されたアドレスの起因するアドレスは、メール輪を防ぐためには「郵便局長」でなければなりません。
These two addresses are RESERVED so they do not conflict with any internal addressing plan.
これらの2つのアドレスがRESERVEDであるので、それらはどんな内部のアドレシングプランとも衝突しません。
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, headers do not indicate delivery options for the transport of messages.
インターネットメッセージはヘッダー情報ブロックを含んでいます。 このヘッダーブロックは送付者を特定するのに必要である情報を含んでいて、受取人のリスト、メッセージはユーザプレゼンテーションのために意図する時間の、そして、他の情報を送ります。 専門化しているゲートウェイとメーリングリストケース以外に、ヘッダーはメッセージの輸送のための配送オプションを示しません。
The following header lines are permitted for use with voice messages.
以下のヘッダー系列は使用のために音声メールで受入れられます。
From
from
The originator's fully-qualified domain address (a mailbox address followed by the fully-qualified domain name). The user listed in this field should be presented in the voice message envelope as the originator of the message.
創始者の完全に適切なドメインアドレス(完全修飾ドメイン名があとに続いたメールボックスアドレス)。 この分野に記載されたユーザはメッセージの創始者として音声メール封筒を紹介されるべきです。
Systems conformant to this profile SHOULD provide the text personal name of the sender in a quoted phrase if available. To facilitate storage of the text name in a local dial-by-name cache directory, the first and last name MUST be separable. Text names in voice messages MUST be represented in the form "last, first, mi." [822].
利用可能であるなら、このプロフィールSHOULDへのシステムconformantは送付者のテキスト個人名を引用された句に提供します。 ローカルの名前のダイヤルキャッシュディレクトリ、1番目、および姓における、原文名のストレージを容易にするのは分離できるに違いありません。 テキストは声が表されたコネがフォームであったに違いないなら通信させるコネを「最終、最初に、マイル」と命名します。 [822].
Vaudreuil Experimental [Page 5] RFC 1911 MIME Voice Profile February 1996
ボードルイの実験的な[5ページ]RFC1911は声のプロフィール1996年2月にまねます。
Example:
例:
From: "User, Joe S." <2145551212@mycompany.com>
From: 「ユーザ、ジョーS.、「 <2145551212@mycompany.com 、gt;、」
To
to
The TO header contains the recipient's fully-qualified domain address. There may be one or more To: fields in any message.
TOヘッダーは受取人の完全に適切なドメインアドレスを含んでいます。 1か、より多くのTo:があるかもしれません。 どんなメッセージの分野。
Systems conformant to this profile SHOULD provide the text personal name of the recipient, if known, in a quoted phrase. The name MUST be in the form "last, first, mi." [822].
引用された句で知られているなら、このプロフィールSHOULDへのシステムconformantは受取人のテキスト個人名を提供します。 名前はフォームで「最初にマイルを持続する」ことであるに違いありません。 [822].
Example:
例:
To: "User, Sam S." <2145551213@mycompany.com>
To: 「ユーザ、サムS.、「 <2145551213@mycompany.com 、gt;、」
Cc
cc
The CC header contains additional recipients' fully-qualified domain addresses. Many voice mail systems are not capable of storing or reporting the full list of recipients to the receiver.
CCヘッダーは追加受取人の完全に適切なドメインアドレスを含んでいます。 受取人の完全リストを受信機に保存できないか、多くのボイスメールシステムは報告できません。
Systems conformant to this profile SHOULD provide the text personal name of the recipient, if known, in a quoted phrase. The name MUST be in the form "last, first, mi." [822].
引用された句で知られているなら、このプロフィールSHOULDへのシステムconformantは受取人のテキスト個人名を提供します。 名前はフォームで「最初にマイルを持続する」ことであるに違いありません。 [822].
Example:
例:
To: "User, Sam S." <2145551213@mycompany.com>
To: 「ユーザ、サムS.、「 <2145551213@mycompany.com 、gt;、」
Systems conformant to this profile may discard the CC list of incoming messages as necessary. Systems conformant to this profile should provide a complete list of recipients when possible.
このプロフィールへのシステムconformantは必要に応じて入力メッセージのCCリストを捨てるかもしれません。 可能であるときに、このプロフィールへのシステムconformantは受取人の全リストを提供するはずです。
Date
日付
The Date header contains the date, time, and time zone in which the message was sent by the originator. Conforming implementations SHOULD be able to convert RFC 822 date and time stamps into local time.
Dateヘッダーはメッセージが創始者によって送られた日付、時間、および時間帯を含んでいます。 実装SHOULDを従わせて、RFC822日時のスタンプを現地時間に変換できてください。
Example:
例:
Date: Wed, 28 Jul 93 10:08:49 PST
日付: 水曜日、1993年7月28日の太平洋標準時10時8分49秒
The sending system MUST report the time the message was sent [822].
[822]をメッセージに送ったとき、送付システムは報告しなければなりません。
Vaudreuil Experimental [Page 6] RFC 1911 MIME Voice Profile February 1996
ボードルイの実験的な[6ページ]RFC1911は声のプロフィール1996年2月にまねます。
Sender
送付者
The Sender header contains the actual address of the originator if the message is sent by an agent on behalf of the author indicated in the From: field. Support for this field cannot be assumed when talking to a voice system and SHOULD NOT be generated by a conforming implementation.
メッセージがFrom:で示された作者を代表してエージェントによって送られるなら、Senderヘッダーは創始者の絶対番地を含んでいます。 さばきます。 音声システムとSHOULD NOTと話すとき、この分野のサポートを想定できません。従う実装で、生成されます。
While it may not be possible to save this information in some voice mail machines, discarding this information or the ESMTP MAIL FROM address will make it difficult to send an error message to the proper destination [822].
いくつかのボイスメールマシンにこの情報を保存するのが可能でないかもしれない間、この情報かESMTP MAIL FROMアドレスを捨てるのに、適切な目的地[822]にエラーメッセージを送るのは難しくなるでしょう。
Message-id
メッセージイド
The Message-id header contains a unique per-message identifier. A unique message-id MUST be generated for each message sent from a conforming implementation.
Message-イドヘッダーは1メッセージあたり1つのユニークな識別子を含んでいます。 従う実装から送られた各メッセージのためにユニークなメッセージイドを生成しなければなりません。
The message-id is not required to be stored on the receiving system. This identifier MAY be used for tracking, auditing, and returning read-receipt reports [822].
メッセージイドは、受電方式の上に保存されるのに必要ではありません。 この識別子は追跡していて、監査の、そして、戻っている領収書を読んでいるレポート[822]に使用されるかもしれません。
Example:
例:
Message-id: <12345678@mycompany.com>
メッセージイド: <12345678@mycompany.com>。
Received
受信します。
The Received header contains trace information added to the beginning of a RFC 822 message by message transport agents (MTA). This is the only header permitted to be added by an MTA. Information in this header is useful for debugging when using an ASCII message reader or a header parsing tool.
Receivedヘッダーはメッセージ転送エージェント(MTA)によってRFC822メッセージの始まりに加えられたトレース情報を含んでいます。 これはMTAによって加えられることが許可された唯一のヘッダーです。 ASCIIメッセージ読者かヘッダー構文解析ツールを使用するとき、このヘッダーの情報はデバッグの役に立ちます。
A conforming system MUST add Received headers when acting as a gateway and must not remove them. These headers MAY be ignored or deleted when the message is received at the final destination [822].
従うシステムは、ゲートウェイとして機能するとき、Receivedヘッダーを加えなければならなくて、彼らを取り除いてはいけません。 最終的な目的地[822]にメッセージを受け取るとき、これらのヘッダーを無視するか、または削除するかもしれません。
MIME Version
MIMEバージョン
The MIME-Version header indicates that the message is conformant to the MIME message format specification. Systems conformant to the voice messaging profile MUST include a comment with the words "(Voice 1.0)" [MIME].
MIMEバージョンヘッダーは、メッセージがMIMEメッセージ書式仕様へのconformantであることを示します。 声のメッセージングプロフィールへのシステムconformantは「(声1.0)」という約束[MIME]によるコメントを含まなければなりません。
Vaudreuil Experimental [Page 7] RFC 1911 MIME Voice Profile February 1996
ボードルイの実験的な[7ページ]RFC1911は声のプロフィール1996年2月にまねます。
Example:
例:
MIME-Version: 1.0 (Voice 1.0)
MIMEバージョン: 1.0 (声1.0)
Content-Type
コンテントタイプ
The content-type header declares the type of content enclosed in the message. One of the allowable contents is multipart, a mechanism for bundling several message components into a single message. The allowable contents are specified in the next section of this document [MIME].
content typeヘッダーはメッセージに同封された内容のタイプを宣言します。 許容できるコンテンツの1つは複合であり、バンドリングのためのメカニズムはただ一つのメッセージへのいくつかのメッセージコンポーネントです。 許容できる内容はこのドキュメント[MIME]の次のセクションで指定されます。
Content-Transfer-Encoding
満足している転送コード化
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. Conformant implementations MUST recognize and decode the standard encodings, "Binary", "7bit, "8bit", "Base-64" and "Quoted- Printable". The allowable content-transfer-encodings are specified in the next section of this document [MIME].
インターネット・メールが初めは7ビットの米国-ASCIIテキストだけを運ぶために指定されたので、その環境に適した表現に声をコード化して、ファックスでデータを送るのが必要であるかもしれません。 それが必要であるなら、転送をコード化する内容ヘッダーはこの変換について説明します。 そして、標準のencodings、「バイナリー」を、Conformant実装が認識して、解読しなければならない、「7に「8ビット」噛み付いた、「基づく、-何64インチも「引用される、印刷可能である、」、」 許容できる満足している転送encodingsはこのドキュメント[MIME]の次のセクションで指定されます。
Sensitivity
感度
The sensitivity header, if present, indicates the requested privacy level. The case-insensitive values "Personal" and "Private" are specified. If no privacy is requested, this field is omitted.
存在しているなら、感度ヘッダーは要求されたプライバシーレベルを示します。 大文字と小文字を区別しない値「個人的で」「個人的」は指定されます。 プライバシーが全く要求されないなら、この分野は省略されます。
If a sensitivity header is present in the message, a conformant system MUST prohibit the recipient from forwarding this message to any other user. If the receiving system does not support privacy and the sensitivity is one of "Personal" or "Private", the message MUST be returned to the sender with an appropriate error code indicating that privacy could not be assured and that the message was not delivered [X400].
感度ヘッダーがメッセージに出席しているなら、conformantシステムはこのメッセージをいかなる他のユーザにも転送するのから受取人を禁じなければなりません。 受電方式がプライバシーをサポートしないで、感度が1であるなら、「個人的である」か「個人的」では、プライバシーを保証できないで、[X400]がメッセージに提供されなかったのを示して、適切なエラーコードをもっている送付者にメッセージを返さなければなりません。
Importance
重要性
Indicates the requested priority to be given by the receiving system. The case-insensitive values "low", "normal" and "high" are specified. If no special importance is requested, this header may be omitted and the value assumed to be "normal".
受電方式によって与えられる要求された優先を示します。 大文字と小文字を区別しない値「安値」、「標準」、および「高値」は指定されます。 どんな特別な重要性も要求されていて、このヘッダーが省略されるかもしれないということでないかどうか、そして、「正常である」と思われた値。
Conformant implementations MAY use this header to indicate the importance of a message and may order messages in a recipient's mailbox [X400].
Conformant実装は、メッセージの重要性を示すのにこのヘッダーを使用して、受信者のメールボックス[X400]の中のメッセージを注文するかもしれません。
Vaudreuil Experimental [Page 8] RFC 1911 MIME Voice Profile February 1996
ボードルイの実験的な[8ページ]RFC1911は声のプロフィール1996年2月にまねます。
Subject
対象
The subject field is often provided by email systems but is not widely supported on Voice Mail platforms. This field MAY be generated by a conforming implementation and may be discarded if present by a receiving system [822].
対象の分野をしばしばメールシステムで提供しますが、Voiceメールプラットホームで広くサポートしません。この分野を従う実装で生成して、受電方式[822]で存在しているなら、捨てるかもしれません。
4.3 Message Content Types
4.3 メッセージcontent type
MIME is a general-purpose message body format that is extensible to carry a wide range of body parts. The basic protocol is described in [MIME]. MIME also provides for encoding binary data so that it can be transported over the 7-bit text-oriented SMTP protocol. This transport encoding is independent of the audio encoding designed to generate a binary object.
MIMEはさまざまな身体の部分を運ぶのにおいて広げることができる汎用メッセージボディー形式です。 基本プロトコルは[MIME]で説明されます。 また、MIMEは7ビットのテキスト指向のSMTPプロトコルの上でそれを輸送できるようにバイナリ・データをコード化するのに提供されます。 この輸送コード化は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 ("Base-64").
While Base-64 is dramatically more efficient for audio data, both
will work. Where binary transport is available, no transport
encoding is needed, and the data can be labeled as "Binary".
MIMEがバイナリ・データを7ビットの表現、テキストのようなデータ(「引用されて印刷可能な」)のために設計されたもの、および任意のバイナリ・データのための1つに変えるために2つの輸送コード化メカニズムを定義する、(「基地64インチ)」 基地-64はオーディオデータには、より効率的であることで、劇的に、両方が働くということですが。 2進の輸送が利用可能であるところでは、輸送コード化でないのを必要とします、そして、「2進である」とデータをラベルできます。
An implementation in conformance with this profile SHOULD send audio data in binary form when binary message transport is available. When binary transport is not available, implementations MUST encode the message as Base-64. 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.
2進のメッセージ転送であるときにSHOULDが二部形式のオーディオデータを送るこのプロフィールによる順応における実装は利用可能です。 2進の輸送が利用可能でないときに、実装は基地-64としてメッセージをコード化しなければなりません。 検出と解読、「引用される、印刷可能である、」、MIME必要条件を満たして、最もふくよかな範囲の可能なデバイスで相互運用性を保存するために「7ビット」、および「8ビット」をサポートしなければなりません。
The following content types are identified for use with this profile. Note that each of these contents can be sent individually in a message or wrapped in a multipart message to send multi-segment messages.
以下のcontent typeはこのプロフィールによる使用のために特定されます。 それぞれのこれらの内容をメッセージで個別に送るか、またはマルチセグメントメッセージを送る複合メッセージで包装できることに注意してください。
Message/RFC822
メッセージ/RFC822
MIME requires support of the Message/RFC822 message encapsulation body part. This body part is used in the Internet to forward complete messages within a multipart/mixed message. Processing of this body part entails trivial processing to decapsulate/encapsulate the message. Systems conformant to this profile SHOULD NOT send this body part but MUST accept if in conformance with basic MIME. Specific handling depends on the platform, and interpretation of this content-type is left as an implementation decision [MIME].
MIMEはMessage/RFC822メッセージカプセル化身体の部分のサポートを必要とします。 この身体の部分は、複合の、または、複雑なメッセージの中で完全なメッセージを転送するのにインターネットで使用されます。 この身体の部分の処理は/がメッセージをカプセル化するdecapsulateに些細な処理を伴います。 順応でこのプロフィールSHOULD NOTへのシステムconformantは基本的なMIMEでこの身体の部分を送りますが、受け入れなければなりません。 特定の取り扱いはプラットホームによります、そして、このcontent typeの解釈は実装決定[MIME]として発たれます。
Vaudreuil Experimental [Page 9] RFC 1911 MIME Voice Profile February 1996
ボードルイの実験的な[9ページ]RFC1911は声のプロフィール1996年2月にまねます。
Text/Plain
テキスト/平野
MIME requires support of the basic Text/Plain content type. This content type has no applicability within the voice messaging environment. Conformant implementations MUST NOT send the Text/Plain content-type. Conformant implementations MUST accept Text/Plain messages, however, specific handling is left as an implementation decision. One option is to return the message to the sender with a media-unsupported error code [MIME].
MIMEは基本的なText/明瞭なcontent typeのサポートを必要とします。 このcontent typeは、環境を通信させながら、声の中に適用性を全く持っていません。 Conformant実装はText/明瞭なcontent typeを送ってはいけません。 Conformant実装はText/明瞭なメッセージを認めなければならなくて、しかしながら、特定の取り扱いは実装決定として残されます。 1つのオプションはメディアサポートされないエラーコード[MIME]をもっている送付者にメッセージを返すことです。
Multipart/Mixed
複合か混ぜられます。
MIME provides the facilities for enclosing several body parts in a single message. Multipart/Mixed MAY be used for sending multi-segment voice messages, that is, to preserve across the network the distinction between an annotation and a forwarded message. Conformant systems MUST accept multipart/mixed body parts. Systems MAY to collapse such a multi-segment message into a single segment if multi-segment messages are not supported on the receiving machine [MIME].
MIMEはただ一つのメッセージでいくつかの身体の部分を同封するのに施設を提供します。 複合の、または、混ぜられた5月が送付マルチセグメント音声メールに使用されて、ネットワークの向こう側に注釈と転送されたメッセージの区別を保存するために、それはいます。 Conformantシステムは複合の、または、混ぜられた身体の部分を受け入れなければなりません。 マルチセグメントメッセージが受信のときにサポートされないなら、そのようなマルチセグメントメッセージをただ一つのセグメントまで潰すシステム5月は[MIME]を機械加工します。
Message/Notification
メッセージ/通知
This MIME body part is used for sending machine-parsable delivery status notifications. Conformant implementations must use the Message/Notification construct when returning messages or sending warnings. Conformant implementations must recognize and decode the Message/Notification content type and present the reason for failure to the user [NOTIFY].
このMIME身体の部分は送付マシン-「パー-可能」配送状態通知に使用されます。 メッセージを返すか、または警告を送るとき、Conformant実装はMessage/通知構造物を使用しなければなりません。 Conformant実装は、Message/通知content typeを認識して、解読しなければならなくて、ユーザ[NOTIFY]に失敗の理由を提示します。
Multipart/Report
複合/レポート
The Multipart/Report is used for enclosing a Message/Notification body part and any returned message content. This body type is a companion to Message/Notification. Conformant implementations must use the Multipart/Report construct when returning messages or sending warnings. Conformant implementations must recognize and decode the Multipart/Report content type [REPORT].
Multipart/レポートは、Message/通知身体の部分とどんな返されたメッセージ内容も同封するのに使用されます。 このボディータイプはMessage/通知への仲間です。 メッセージを返すか、または警告を送るとき、Conformant実装はMultipart/レポート構造物を使用しなければなりません。 Conformant実装は、Multipart/レポートcontent type[REPORT]を認識して、解読しなければなりません。
Audio/32KADPCM
オーディオ/32KADPCM
CCITT Recommendation G.721 [G721] describes the algorithm recommended for conversion of a 64 KB/s A-law or u-law PCM channel to and from a 32 KB/s channel. The conversion is applied to the PCM stream using an Adaptive Differential Pulse Code Modulation (ADPCM) transcoding technique. This algorithm will be registered with the IANA for MIME use under the name Audio/32KADPCM.
CCITT Recommendation G.721[G721]は64KB/sのA-法かu-法のPCMチャンネルの変換のためにチャンネルと32KB/sのチャンネルから推薦されたアルゴリズムを説明します。 変換は、Adaptive Differentialパルスコードの変調(ADPCM)コード変換のテクニックを使用することでPCMストリームに適用されます。 このアルゴリズムはAudio/32KADPCMという名でMIME使用のためにIANAに登録されるでしょう。
Vaudreuil Experimental [Page 10] RFC 1911 MIME Voice Profile February 1996
ボードルイの実験的な[10ページ]RFC1911は声のプロフィール1996年2月にまねます。
An implementation conformant to this profile MUST use Audio/32KADPCM by default.
このプロフィールへの実装conformantはデフォルトでAudio/32KADPCMを使用しなければなりません。
Proprietary Voice Formats
独占声の形式
Proprietary voice encoding formats or other standard formats may be supported under this profile provided a unique identifier is registered with the IANA prior to use. These encodings should be registered as sub-types of Audio.
ユニークな識別子が使用の前のIANAに登録されるなら、独占声のコード化形式か他の標準書式がこのプロフィールの下でサポートされるかもしれません。 これらのencodingsはAudioのサブタイプとして登録されるべきです。
Use of any other encoding except Audio/32KADPCM reduces interoperability in the absence of explicit manual system configuration. A conformant implementation MAY use any other encoding with explicit per-destination configuration.
Audio/32KADPCMを除いたいかなる他のコード化の使用も明白なマニュアル・システム構成がないとき相互運用性を減少させます。 conformant実装は1目的地あたりの明白な構成と共にいかなる他のコード化も使用するかもしれません。
Multipart/Voice-Message
複合かメッセージを声に出します。
This new MIME multipart structure provides a mechanism for packaging the senders spoken name, a spoken subject and, the message. The multipart provides for the packaging of three segments, the first is the spoken name, the second is a spoken subject, and the third is the message itself. Forwarded messages can be created by simply nesting multipart content-types (this is also possible with Multipart/Mixed if spoken name or spoken subject is not present). This type is defined in an appendix to this document.
そして、この新しいMIME複合構造が話された名前、話された対象を送付者をパッケージするためのメカニズムに供給する、メッセージ。 複合は3つのセグメントのパッケージに備えます、そして、1番目は話された名前です、そして、2番目は話された対象です、そして、3番目はメッセージ自体です。 単に複合content typeを入れ子にすることによって、転送されたメッセージを作成できます(また、話された名前か話された対象が存在していないなら、これもMultipart/Mixedで可能です)。 このタイプは付録でこのドキュメントと定義されます。
Conforming implementations MUST send the Multipart/Voice-Message if a spoken name or spoken subject is available. Conforming implementations SHOULD recognize the Multipart/Voice-Message and separate the spoken name or spoken subject.
実装を従わせると、話された名前か話された対象が利用可能であるなら、声Multipart/メッセージは送られなければなりません。 従っている実装SHOULDは声Multipart/メッセージを認識して、話された名前か話された対象を分離します。
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 networking 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 traditionally been transported by encoding the messages into a 7-bit text-like form. [ESMTP] was recently published and formalized an extension mechanism for SMTP, and subsequent RFCs have defined 8-bit
ESMTPはともにメールを送って、端末のコンソールメッセージングを許容するように設計された汎用メッセージング・プロトコルです。 簡単なメールTransportプロトコル(SMTP)は元々、米国-ASCIIの7ビットのテキスト・メッセージの交換のために作成されました。 2進の、そして、8ビットのテキスト・メッセージは、7ビットのテキストのようなフォームにメッセージをコード化することによって、伝統的に輸送されました。 [ESMTP]は、最近、発行されて、SMTPのために拡張機能を正式にしました、そして、その後のRFCsは8ビットを定義しました。
Vaudreuil Experimental [Page 11] RFC 1911 MIME Voice Profile February 1996
ボードルイの実験的な[11ページ]RFC1911は声のプロフィール1996年2月にまねます。
text networking, binary networking, and extensions to permit the declaration of message size for the efficient transmission of large messages such as multi-minute voice mail.
マルチ分ボイスメールなどの大きいメッセージの効率的な伝達のためにメッセージサイズの宣言を可能にするテキストネットワーク、2進のネットワーク、および拡大。
A command streaming extension for high performance message transmission has been defined [PIPE]. This extension reduces the number of round-trip packet exchanges and makes it possible to validate all recipient addresses in one operation. This extension is optional but recommended.
高性能メッセージ送信のための拡大を流すコマンドは定義されました[PIPE]。 この拡大で、往復のパケット交換の数を減少させて、一挙にすべての受取人アドレスを有効にするのは可能になります。 この拡大は、任意ですが、お勧めです。
The following sections list ESMTP commands, keywords, and parameters that are required and those that are optional.
以下のセクションはESMTPコマンド、キーワード、必要であるパラメタ、および任意のものをリストアップします。
5.1 ESMTP Commands
5.1 ESMTPコマンド
HELO
HELO
Base SMTP greeting and identification of sender. This command is not to be sent by conforming systems unless the more-capable EHLO command is not accepted. It is included for compatibility with general SMTP implementations. Conforming implementations MUST implement the HELO command for backward compatibility but SHOULD NOT send it unless EHLO is not supported [SMTP].
送付者のSMTP挨拶と識別を基礎づけてください。 このコマンドは、よりできるEHLOコマンドを受け入れる場合システムを従わせることによって送られないことです。 それは一般的なSMTP実装との互換性のために含まれています。 実装を従わせるのは、HELOが後方の互換性のためのコマンドであると実装しなければなりませんが、EHLOが[SMTP]であるとサポートされる場合、SHOULD NOTはそれを送ります。
MAIL FROM (REQUIRED)
メール(必要)です。
Originating mailbox. This address contains the mailbox to which errors should be sent. This address may not be the same as the message sender listed in the message header fields if the message was received from a gateway or sent to an Internet-style mailing list. Conforming implementations MUST implement the extended MAIL FROM command [SMTP, ESMTP].
メールボックスを溯源します。 このアドレスは誤りが送られるべきであるメールボックスを含んでいます。 このアドレスはメッセージをゲートウェイから受け取ったか、またはインターネットスタイルメーリングリストに送ったならメッセージ送付者がメッセージヘッダーフィールドで記載したのと同じでないかもしれません。 実装を従わせるのは、拡張MAIL FROMがコマンド[SMTP、ESMTP]であると実装しなければなりません。
RCPT TO
RCPT
Recipient's mailbox. This field contains only the addresses to which the message should be delivered for this transaction. In the event that multiple transport connections to multiple destination machines are required for the same message, this list may not match the list of recipients in the message header. Conforming implementations MUST implement the extended RCPT TO command [SMTP, ESMTP].
受信者のメールボックス。 この分野はメッセージがこのトランザクションのために提供されるべきであるアドレスだけを含んでいます。 複数の目的地マシンへの複数の輸送の接続が同じメッセージに必要である場合、このリストはメッセージヘッダーで受取人のリストに合わないかもしれません。 実装を従わせるのは、拡張RCPT TOがコマンド[SMTP、ESMTP]であると実装しなければなりません。
DATA
データ
Initiates the transfer of message data. Support for this command is required in the event the binary mode command BDAT is not supported by the remote system. Conforming implementations MUST implement the SMTP DATA command for backwards compatibility [SMTP].
メッセージデータの転送を起こします。 このコマンドのサポートがバイナリ・モードコマンドBDATがリモートシステムでサポートされないイベントで必要です。 実装を従わせるのは、後方にSMTP DATAコマンドが互換性[SMTP]であると実装しなければなりません。
Vaudreuil Experimental [Page 12] RFC 1911 MIME Voice Profile February 1996
ボードルイの実験的な[12ページ]RFC1911は声のプロフィール1996年2月にまねます。
TURN
回転
Requests a change-of-roles, that is, the client that opened the connection offers to assume the role of server for any mail the remote machine may wish to send. Because SMTP is not an authenticated protocol, the TURN command presents an opportunity to improperly fetch mail queued for another destination. Conforming implementations SHOULD NOT implement the TURN command [SMTP].
いずれもリモートマシンを郵送するので、すなわち、役割の変化、接続を開いたクライアントがサーバの役割であると仮定すると申し出る要求は発信したがっているかもしれません。 SMTPが認証されたプロトコルでないので、TURNコマンドは不適切に別の目的地へ列に並ばせられたメールをとって来る機会を提示します。 従っている実装SHOULD NOTは、TURNがコマンド[SMTP]であると実装します。
QUIT
やめてください。
Requests that the connection be closed. If accepted, the remote machine will reset and close the connection. Conforming implementations MUST implement the QUIT command [SMTP].
接続が閉店するという要求。 受け入れると、リモートマシンは、接続をリセットして、終えるでしょう。 実装を従わせるのは、QUITがコマンド[SMTP]であると実装しなければなりません。
RSET
RSET
Resets the connection to its initial state. Conforming implementations MUST implement the RSET command [SMTP].
初期状態に接続をリセットします。 実装を従わせるのは、RSETがコマンド[SMTP]であると実装しなければなりません。
VRFY
VRFY
Requests verification that this node can reach the listed recipient. While this functionality is also included in the RCPT TO command, VRFY allows the query without beginning a mail transfer transaction. This command is useful for debugging and tracing problems. Conforming implementations MAY implement the VRFY command [SMTP].
このノードがそうすることができる要求検証は記載された受取人に届きます。 また、この機能性はRCPT TOコマンドに含まれていますが、メール振替取引を始めないで、VRFYは質問を許します。 このコマンドは問題をデバッグして、たどることの役に立ちます。実装を従わせるのは、VRFYがコマンド[SMTP]であると実装するかもしれません。
(Note that the implementation of VRFY may simplify the guessing of a recipient's mailbox or automated sweeps for valid mailbox addresses, resulting in a possible reduction in privacy. Various implementation techniques may be used to reduce the threat, such as limiting the number of queries per session [SMTP].)
(VRFYの実装が有効なメールボックスアドレスのために受信者のメールボックスか自動化された視聴率調査期間の推測を簡素化するかもしれないことに注意してください、プライバシーの可能な減少をもたらして。 様々な実装のテクニックは、セッション[SMTP]あたりの質問の数を制限などなどの脅威を抑えるのに使用されるかもしれません。)
EHLO
EHLO
The enhanced mail greeting that enables a server to announce support for extended messaging options. The extended messaging modes are discussed in a later section of this document. Conformant implementations MUST implement the ESMTP command and return the capabilities indicated later in this memo [ESMTP].
それに挨拶する高められたメールは、サーバが拡張メッセージングオプションのサポートを発表するのを可能にします。 このドキュメントの後のセクションで拡張メッセージングモードについて議論します。 Conformant実装は、このメモ[ESMTP]でESMTPがコマンドであると実装して、後で示された能力を返さなければなりません。
BDAT
BDAT
The BDAT command provides a higher efficiency alternative to the earlier DATA command, especially for voice. The BDAT command provides for native binary transport. Because voice messages are large binary objects otherwise subject to BASE-64 encoding, BDAT will result in a
BDATコマンドは特に声のための以前のDATAコマンドへの、より高い効率代替手段を提供します。 BDATコマンドはネイティブの2進の輸送に備えます。 音声メールがそうでなければ、基地-64コード化を条件とした大きい2進のオブジェクトであるので、BDATはaをもたらすでしょう。
Vaudreuil Experimental [Page 13] RFC 1911 MIME Voice Profile February 1996
ボードルイの実験的な[13ページ]RFC1911は声のプロフィール1996年2月にまねます。
substantial improvement in transmission efficiency over DATA. Conformant implementations SHOULD support binary transport using the BDAT command [BINARY].
DATAの上の伝達効率における実質的な改善。 Conformant実装SHOULDは、BDATコマンド[BINARY]を使用することで2進の輸送をサポートします。
5.2 ESMTP Capabilities
5.2 ESMTP能力
The following ESMTP keywords indicate extended features useful for voice messaging.
以下のESMTPキーワードは声のメッセージングの役に立つ拡張特徴を示します。
PIPELINING
パイプライン処理
The "PIPELINING" keyword indicates ability of the receiving SMTP to accept pipelined commands. Pipelining commands dramatically improves the protocol performance over wide area networks. Conformant implementations SHOULD support the command pipelining indicated by this parameter [PIPE].
「パイプライン処理」キーワードは、受信SMTPが受け入れる能力がコマンドをpipelinedしたのを示します。 広域ネットワークの上のプロトコル性能を劇的に向上させますパイプライン処理が、命令する。 Conformant実装SHOULDはこのパラメタ[PIPE]によって示されたコマンド連続送信をサポートします。
SIZE
サイズ
The "SIZE" keyword provides a mechanism by which the receiving SMTP can indicate the maximum size message supported. Conformant implementations MUST provide the size capability and SHOULD honor any size limitations when sending [SIZE].
「サイズ」キーワードは受信SMTPが、最大サイズメッセージがサポートしたのを示すことができるメカニズムを提供します。 [SIZE]を送るとき、Conformant実装は、能力をサイズに提供して、どんなサイズ制限もSHOULD名誉に提供しなければなりません。
CHUNKING
分魂化
The "CHUNKING" keyword indicates that the receiver will support the high-performance binary transport mode. Note that CHUNKING can be used with any message format and does not imply support for binary encoded messages. Conformant implementations SHOULD support binary transport indicated by this capability [BINARY].
「分魂化」キーワードは、受信機が、高性能が2進の交通機関であるとサポートするのを示します。 CHUNKINGが、どんなメッセージ・フォーマットと共にも使用できて、バイナリーのサポートがメッセージをコード化したのを含意しないことに注意してください。 Conformant実装SHOULDはこの能力[BINARY]によって示された2進の輸送をサポートします。
BINARYMIME
BINARYMIME
The "BINARYMIME" keyword indicates that the receiver SMTP can accept binary encoded MIME messages. Conformant implementations should support binary transport indicated by this capability [BINARY].
"BINARYMIME"キーワードは、SMTPが2進であると受け入れることができる受信機がMIMEメッセージをコード化したのを示します。 Conformant実装はこの能力[BINARY]によって示された2進の輸送をサポートするべきです。
NOTIFY
通知してください。
The "NOTIFY" keyword indicates that the receiver SMTP will accept explicit delivery status notification requests. Conformant implementations MUST support the delivery notification extensions in [DSN].
「通知してください」というキーワードは、受信機SMTPが明白な配送状態通知要求を受け入れるのを示します。 Conformant実装は、[DSN]で配送通知が拡大であるとサポートしなければなりません。
Vaudreuil Experimental [Page 14] RFC 1911 MIME Voice Profile February 1996
ボードルイの実験的な[14ページ]RFC1911は声のプロフィール1996年2月にまねます。
5.3 ESMTP Parameters - MAIL FROM
5.3 ESMTPパラメタ--メール
BINARYMIME
BINARYMIME
The current message is a binary encoded MIME messages. Conformant implementations SHOULD support binary transport indicated by this parameter [BINARY].
現在のメッセージはバイナリーがMIMEメッセージをコード化したということです。 Conformant実装SHOULDはこのパラメタ[BINARY]によって示された2進の輸送をサポートします。
5.4 ESMTP Parameters - RCPT TO
5.4 ESMTPパラメタ--RCPT
NOTIFY
通知してください。
The NOTIFY parameter indicates the conditions under which a delivery report SHOULD be sent. Conformant implementations must honor this request [DSN].
NOTIFYパラメタは、配送がSHOULDを報告する状態が送られるのを示します。 Conformant実装はこの要求[DSN]を光栄に思わなければなりません。
RET
浸水してください。
The RET parameter indicates whether the content of the message should be returned. Conformant systems SHOULD honor a request for returned content [DSN].
RETパラメタは、メッセージの内容が返されるべきであるかどうかを示します。 ConformantシステムSHOULDは返された内容[DSN]に関する要求を光栄に思います。
6. Management Protocols
6. 管理プロトコル
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 compliant message machine.
インターネットプロトコルはメッセージシステムの管理にメカニズムを提供します、物理ネットワークの経営からメッセージキューの管理で。 SNMPは言いなりになっているメッセージマシンの上でサポートされるべきです。
6.1 Network Management
6.1 ネットワークマネージメント
The digital interface to the VM and the TCP/IP protocols SHOULD be managed. MIB II SHOULD be implemented to provide basic statistics and reporting of TCP and IP protocol performance [MIB II].
デジタルはVMとTCP/IPプロトコルSHOULDに連結します。管理されます。 基本的な統計を提供するために実装されて、TCPとIPについて報告するMIB II SHOULDが性能[MIB II]について議定書の中で述べます。
6.2 Directory and Message Management
6.2ディレクトリとメッセージ管理
Conformant systems SHOULD provide for the management of message traffic and queue monitoring based on the Message and Directory MIB [MADMAN].
ConformantシステムSHOULDはメッセージトラフィックの管理に備えて、MessageとディレクトリMIBに基づくモニターを列に並ばせます[MADMAN]。
7. References
7. 参照
[MIME] Borenstein, N., and N. Freed, "Multipurpose Internet Mail
Extensions", RFC 1521, Bellcore, Innosoft, September 1993.
[まねます] Borenstein、N.と解放されたN.、「マルチパーパスインターネットメールエクステンション」、RFC1521、Bellcore、Innosoft、1993年9月。
[MSG822] Crocker, D., "Standard for the Format of ARPA Internet Text
Messages", STD 11, RFC 822, UDEL, August 1982.
[MSG822] クロッカー、D.、「アルパインターネットテキスト・メッセージの形式の規格」、STD11、RFC822、UDEL、1982年8月。
Vaudreuil Experimental [Page 15] RFC 1911 MIME Voice Profile February 1996
ボードルイの実験的な[15ページ]RFC1911は声のプロフィール1996年2月にまねます。
[X400] Hardcastle-Kille, S., "Mapping between X.400(1988) / ISO
10021 and RFC 822", RFC 1327, UCL, May 1992.
[X400]Hardcastle-Kille、S.、「X.400(1988)/ISO10021とRFC822インチの間のマッピング、RFC1327、UCL、5月1992日
[PIPE] Freed, N., and A. Cargille, "SMTP Service Extension for
Command Pipelining", RFC 1854, October 1995.
[運びます] フリード、N.、およびA.Cargille、「コマンド連続送信のためのSMTPサービス拡張子」、RFC1854、10月1995。
[ESMTP] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D.
Crocker, "SMTP Service Extensions", RFC 1869, United Nations
University, Innosoft International, Inc., Dover Beach
Consulting, Inc., Network Management Associates, Inc., The
Branch Office, November 1995.
[ESMTP]Klensin、J.、解放されています、N.とローズとM.とStefferud、E.とD.クロッカー、「SMTPサービス拡張子」、RFC1869、国連大学、Innosoftの国際Inc.、ドーヴァービーチコンサルティングInc.、ネットワークマネージメントはInc.を関連づけます、支店、1995年11月。
[SIZE] Klensin, J, Freed, N., Moore, K, "SMTP Service Extensions for
Message Size Declaration", RFC 1870, United Nations
University, Innosoft International, Inc., November 1995.
Klensin(J)が解放した[サイズ]、N.、ムーア、K、「SMTPはメッセージサイズ宣言のための拡大を修理します」、RFC1870、国連大学、Innosoftの国際Inc.、1995年11月。
[8BIT] Klensin, J., Freed, N., Rose, M., Stefferud, E., D. Crocker,
"SMTP Service Extension for 8bit-MIMEtransport", RFC 1426,
United Nations University, Innosoft International, Inc.,
Dover Beach Consulting, Inc., Network Management Associates,
Inc., The Branch Office, February 1993.
Klensin(J.)が解放した[8ビット]、N.、ローズ、M.、Stefferud、E.、D.クロッカー、「8ビット-MIMEtransportのためのSMTPサービス拡張子」、RFC1426、国連大学、Innosoftの国際Inc.、ドーヴァービーチコンサルティングInc.、ネットワークマネージメントはInc.を関連づけます、支店、1993年2月。
[DNS1] Mockapetris, P., "Domain Names - Implementation and
Specification", STD 13, RFC 1035, USC/Information Sciences
Institute, November 1987.
[DNS1]Mockapetris、P.、「ドメイン名--、実装と仕様、」、STD13、RFC1035、科学が設けるUSC/情報、11月1987日
[DNS2] Mockapetris, P., "Domain Names - Concepts and Facilities",
STD 13, RFC 1034, USC/Information Sciences Institute,
November 1987.
[DNS2]Mockapetris、P.、「ドメイン名--、概念と施設、」、STD13、RFC1034、科学が設けるUSC/情報、11月1987日
[SMTP] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
USC/Information Sciences Institute, August 1982.
[SMTP] ポステル、J.、「簡単なメール転送プロトコル」、STD10、RFC821、科学が1982年8月に設けるUSC/情報。
[BINARY] Vaudreuil, G., "SMTP Service Extensions for Transmission of
Large and Binary MIME Messages", RFC 1830, Octel Network
Services, October 1995.
[2進]のボードルイ、G.、「SMTPは大きくて2進のMIMEメッセージの伝達のための拡大を修理します」、RFC1830、Octelネットワーク・サービス、1995年10月。
[NOTIFY] Moore, K., and G. Vaudreuil, "An Extensible Message
Format for Delivery Status Notifications", RFC 1894,
University of Tennessee, Octel Network Services, January
1996.
[通知します] ムーア、K.、およびG.ボードルイ、「配送状態通知のための広げることができるメッセージ・フォーマット」、RFC1894、テネシー大学、Octelはサービス(1996年1月)をネットワークでつなぎます。
[REPORT] Vaudreuil, G., "The Multipart/Report Content Type for the
Reporting of Mail System Administrative Messages", RFC
1892, Octel Network Services, January 1996.
[報告します] ボードルイ、G.、「メールのシステムの管理メッセージの報告のための複合/レポートcontent type」、RFC1892、Octelはサービス(1996年1月)をネットワークでつなぎます。
Vaudreuil Experimental [Page 16] RFC 1911 MIME Voice Profile February 1996
ボードルイの実験的な[16ページ]RFC1911は声のプロフィール1996年2月にまねます。
[DSN] Moore, K., "SMTP Service Extensions for Delivery Status
Notifications", RFC 1891, University of Tennessee, January
1996.
[DSN] ムーア、K.、「配送状態通知のためのSMTPサービス拡張子」、RFC1891、テネシー大学、1996年1月。
[G721] CCITT Recommendation G.700-G.795 (1988), General Aspects of
Digital Transmission Systems, Terminal Equipment. Blue Book.
[G721]CCITT推薦G.700-G.795(1988)、デジタル伝送方式、端末装置の一般局面。 紳士録。
[MADMAN] Freed, N., and S. Kille, "Mail Monitoring MIB", RFC 1566,
January 1994.
1994年1月の解放された[狂人]のN.、およびS.Kille、「メールのモニターしているMIB」RFC1566。
[MIB II] Rose, M., "Management Information Base for Network
Management of TCP/IP-based internets: MIB-II", RFC 1158,
May 1990.
[MIB II]ローズ、M.、「TCP/IPベースのインターネットのNetwork Managementのための管理Information基地:」 「MIB-II」(RFC1158)は1990がそうするかもしれません。
8. Security Consideration
8. 警備上の配慮
This document is a profile of existing Internet mail protocols. As such, it does not create any security issues not already existing in the profiled Internet mail protocols themselves.
このドキュメントは既存のインターネットメールプロトコルのプロフィールです。 そういうものとして、それは輪郭を描かれたインターネットメールプロトコル自体で既に存在しない少しの安全保障問題も作成しません。
9. Acknowledgments
9. 承認
The author would like to offer special thanks to Glenn Parsons/BNR for his extensive review, helpful suggestions, and extensive editing including the requirements matrix.
作者は要件マトリクスを含む彼の大量のレビュー、役立つ提案、および大規模な編集のためにグレンパーソンズ/BNRに特別な感謝を提供したがっています。
10. Author's Address
10. 作者のアドレス
Gregory M. Vaudreuil Octel Network Services 17080 Dallas Parkway Dallas, TX 75248-1905
ダラスParkwayダラス、グレゴリーM.ボードルイのOctelネットワーク・サービス17080テキサス75248-1905
Phone/Fax: +1-214-733-2722 EMail: Greg.Vaudreuil@Octel.Com
電話/Fax: +1-214-733-2722 メールしてください: Greg.Vaudreuil@Octel.Com
Vaudreuil Experimental [Page 17] RFC 1911 MIME Voice Profile February 1996
ボードルイの実験的な[17ページ]RFC1911は声のプロフィール1996年2月にまねます。
11. Appendix - MIME/ESMTP Voice Profile Requirements Summary
11. 付録--MIME/ESMTP声のプロフィール要件概要
| | | | |S| |
| | | | |H| |F
| | | | |O|M|o
| | |S| |U|U|o
| | |H| |L|S|t
| |M|O| |D|T|n
| |U|U|M| | |o
| |S|L|A|N|N|t
| |T|D|Y|O|O|t
FEATURE |SECTION | | | |T|T|e
-------------------------------------------|----------|-|-|-|-|-|-
| | | | | | |
Message Addressing Formats: | | | | | | |
Use DNS host names |4.1 |x| | | | |
Use only numbers in mailbox IDs |4.1 | |x| | | |
Use alpha-numeric mailbox IDs |4.1 | | |x| | |
Support of postmaster@domain |4.1 | |x| | | |
Support of loopback@domain |4.1 | |x| | | |
| | | | | | |
Message Header Fields: | | | | | | |
Encoding outbound messages | | | | | | |
From |4.2 |x| | | | |
Addition of text personal name |4.2 | |x| | | |
To |4.2 |x| | | | |
Addition of text personal name |4.2 | |x| | | |
CC |4.2 | | |x| | |
Date |4.2 |x| | | | |
Sender |4.2 | | | |x| |
Message-id |4.2 | |x| | | |
Received |4.2 |x| | | | |
MIME Version: 1.0 (Voice 1.0) |4.2 |x| | | | |
Content-Type |4.2 |x| | | | |
Content-Transfer-Encoding |4.2 |x| | | | |
Sensitivity |4.2 | | |x| | |
Importance |4.2 | | |x| | |
Subject |4.2 | | |x| | |
Detection & Decoding inbound messages | | | | | | |
From |4.2 |x| | | | |
Utilize text personal name |4.2 | |x| | | |
To |4.2 |x| | | | |
Utilize text personal name |4.2 | | |x| | |
CC |4.2 | | |x| | |
Utilize text personal name |4.2 | | |x| | |
Date |4.2 |x| | | | |
Conversion of Date to local time |4.2 | |x| | | |
Sender |4.2 | | | |x| |
| | | | |S| | | | | | |H| |F| | | | |O|M|o | | |S| |U|U|o | | |H| |L|S|t| |M|O| |D|T|n| |U|U|M| | |o | |S|L|A|N|N|t| |T|D|Y|O|O|t FEATURE|セクション| | | |T|T|e-------------------------------------------|----------|-|-|-|-|-|- | | | | | | | メッセージアドレス指定形式: | | | | | | | DNSホスト名を使用してください。|4.1 |x| | | | | メールボックスIDに数だけを使用してください。|4.1 | |x| | | | アルファベット数字式メールボックスIDを使用してください。|4.1 | | |x| | | postmaster@domain のサポート|4.1 | |x| | | | loopback@domain のサポート|4.1 | |x| | | | | | | | | | | メッセージヘッダーフィールド: | | | | | | | 外国行きのメッセージをコード化します。| | | | | | | from|4.2 |x| | | | | テキスト個人名の追加|4.2 | |x| | | | to|4.2 |x| | | | | テキスト個人名の追加|4.2 | |x| | | | CC|4.2 | | |x| | | 日付|4.2 |x| | | | | 送付者|4.2 | | | |x| | メッセージイド|4.2 | |x| | | | 受信します。|4.2 |x| | | | | バージョンをまねてください: 1.0 (声1.0)|4.2 |x| | | | | コンテントタイプ|4.2 |x| | | | | 満足している転送コード化|4.2 |x| | | | | 感度|4.2 | | |x| | | 重要性|4.2 | | |x| | | 対象|4.2 | | |x| | | 検出とDecodingの本国行きのメッセージ| | | | | | | from|4.2 |x| | | | | テキスト個人名を利用してください。|4.2 | |x| | | | to|4.2 |x| | | | | テキスト個人名を利用してください。|4.2 | | |x| | | CC|4.2 | | |x| | | テキスト個人名を利用してください。|4.2 | | |x| | | 日付|4.2 |x| | | | | 現地時間までのDateの変換|4.2 | |x| | | | 送付者|4.2 | | | |x| |
Vaudreuil Experimental [Page 18] RFC 1911 MIME Voice Profile February 1996
ボードルイの実験的な[18ページ]RFC1911は声のプロフィール1996年2月にまねます。
Message ID |4.2 |x| | | | |
Received |4.2 | |x| | | |
MIME Version: 1.0 (Voice 1.0) |4.2 |x| | | | |
Content Type |4.2 |x| | | | |
Content-Transfer-Encoding |4.2 |x| | | | |
Sensitivity |4.2 |x| | | | |1
Importance |4.2 | | |x| | |
Subject |4.2 | | |x| | |
| | | | | | |
Binary Content Encoding: | | | | | | |
Encoding outbound messages | | | | | | |
7BITMIME |4.3 | | | | |x|
8BITMIME |4.3 | | | | |x|
Quoted Printable |4.3 | | | | |x|
Base-64 |4.3 |x| | | | |2
Binary |4.3 |x| | | | |3
Detection & decoding inbound messages | | | | | | |
7BITMIME |4.3 |x| | | | |
8BITMIME |4.3 |x| | | | |
Quoted Printable |4.3 |x| | | | |
Base-64 |4.3 |x| | | | |
Binary |4.3 |x| | | | |
| | | | | | |
Message Content Types: | | | | | | |
Inclusion in outbound messages | | | | | | |
Message/RFC822 |4.3 | | | |x| |
Text/plain |4.3 | | | | |x|
Multipart/Mixed |4.3 | | |x| | |
Message/Notification |4.3 |x| | | | |
Multipart/Report |4.3 |x| | | | |
Audio/32KADPCM |4.3 |x| | | | |
Audio/* (proprietary encodings) |4.3 | | |x| | |
Multipart/Voice-Message |4.3 |X| | | | |
Detection & decoding in inbound messages | | | | | | |
Message/RFC822 |4.3 |x| | | | |
Text/plain |4.3 |x| | | | |
Multipart/Mixed |4.3 |x| | | | |
Message/Notification |4.3 |x| | | | |
Multipart/Report |4.3 |x| | | | |
Audio/32KADPCM |4.3 |x| | | | |
Audio/* (proprietary encodings) |4.3 | | |x| | |
Multipart/Voice-Message |4.3 |X| | | | |
| | | | | | |
Message Transport Protocol: | | | | | | |
ESMTP Commands | | | | | | |
HELO |5.1 |x| | | | |
MAIL FROM |5.1 |x| | | | |
RCPT TO |5.1 |x| | | | |
メッセージID|4.2 |x| | | | | 受信します。|4.2 | |x| | | | バージョンをまねてください: 1.0 (声1.0)|4.2 |x| | | | | content type|4.2 |x| | | | | 満足している転送コード化|4.2 |x| | | | | 感度|4.2 |x| | | | |1 重要性|4.2 | | |x| | | 対象|4.2 | | |x| | | | | | | | | | 以下をコード化する2進の内容 | | | | | | | 外国行きのメッセージをコード化します。| | | | | | | 7BITMIME|4.3 | | | | |x| 8BITMIME|4.3 | | | | |x| 引用、印刷可能|4.3 | | | | |x| 基地-64|4.3 |x| | | | |2バイナリー|4.3 |x| | | | |3 検出と本国行きのメッセージを解読すること。| | | | | | | 7BITMIME|4.3 |x| | | | | 8BITMIME|4.3 |x| | | | | 引用、印刷可能|4.3 |x| | | | | 基地-64|4.3 |x| | | | | バイナリー|4.3 |x| | | | | | | | | | | | メッセージcontent type: | | | | | | | 外国行きのメッセージでの包含| | | | | | | メッセージ/RFC822|4.3 | | | |x| | テキスト/平野|4.3 | | | | |x| 複合か混ぜられます。|4.3 | | |x| | | メッセージ/通知|4.3 |x| | | | | 複合/レポート|4.3 |x| | | | | オーディオ/32KADPCM|4.3 |x| | | | | オーディオ/*(独占encodings)|4.3 | | |x| | | 複合かメッセージを声に出します。|4.3 |X| | | | | 検出と本国行きのメッセージで解読すること。| | | | | | | メッセージ/RFC822|4.3 |x| | | | | テキスト/平野|4.3 |x| | | | | 複合か混ぜられます。|4.3 |x| | | | | メッセージ/通知|4.3 |x| | | | | 複合/レポート|4.3 |x| | | | | オーディオ/32KADPCM|4.3 |x| | | | | オーディオ/*(独占encodings)|4.3 | | |x| | | 複合かメッセージを声に出します。|4.3 |X| | | | | | | | | | | | メッセージ転送プロトコル: | | | | | | | ESMTPコマンド| | | | | | | HELO|5.1 |x| | | | | メール|5.1 |x| | | | | RCPT|5.1 |x| | | | |
Vaudreuil Experimental [Page 19] RFC 1911 MIME Voice Profile February 1996
ボードルイの実験的な[19ページ]RFC1911は声のプロフィール1996年2月にまねます。
DATA |5.1 |x| | | | |
TURN |5.1 | | | | |x|
QUIT |5.1 |x| | | | |
RSET |5.1 |x| | | | |
VRFY |5.1 | | |x| | |
EHLO |5.1 |x| | | | |
BDAT |5.1 | |x| | | |3
ESMTP Keywords | | | | | | |
PIPELINING |5.2 | |x| | | |
SIZE |5.2 |x| | | | |
CHUNKING |5.2 | |x| | | |
BINARYMIME |5.2 | |x| | | |
NOTIFY |5.2 |x| | | | |
| | | | | | |
Management Protocols: | | | | | | |
Network management |6.1 | |x| | | |
Monitoring queues |6.2 | |x| | | |
-------------------------------------------|----------|-|-|-|-|-|-
データ|5.1 |x| | | | | 回転|5.1 | | | | |x| やめてください。|5.1 |x| | | | | RSET|5.1 |x| | | | | VRFY|5.1 | | |x| | | EHLO|5.1 |x| | | | | BDAT|5.1 | |x| | | |3 ESMTPキーワード| | | | | | | パイプライン処理|5.2 | |x| | | | サイズ|5.2 |x| | | | | 分魂化|5.2 | |x| | | | BINARYMIME|5.2 | |x| | | | 通知してください。|5.2 |x| | | | | | | | | | | | 管理プロトコル: | | | | | | | ネットワークマネージメント|6.1 | |x| | | | モニターしている待ち行列|6.2 | |x| | | | -------------------------------------------|----------|-|-|-|-|-|-
1. 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.
2. When binary transport is not available
3. When binary transport is available
1. 感度をサポートしないシステムで機密のメッセージを受け取るなら、適切なエラー通知と共にそれを創始者に返さなければなりません。 2. 2進の輸送が利用可能な3でないときに。 2進の輸送が利用可能であるときに
12. Appendix - Example Voice Message
12. 付録--例の音声メール
The following message is a full-featured, all-options-enabled message addressed to two recipients. The message includes the sender's spoken name and a short speech segment. The message is marked as important and private.
以下のメッセージは2人の受取人に扱われた可能にされた完全装備のオールオプションメッセージです。 メッセージは送付者の話された名前と簡潔なスピーチセグメントを含んでいます。 メッセージは重要で個人的であるとしてマークされます。
To: 2145551212@vm1.mycompany.com
To: "Parsons, Glenn, W." 2145551234@VM1.mycompany.com
From: "Vaudreuil, Greg" 2175552345@VM2.mycompany.com
Date: Mon, 26 Aug 93 10:20:20 CST
MIME-Version: 1.0 (Voice 1.0)
Content-type: Multipart/Voice-Message; Boundary = "MessageBoundary"
Content-Transfer-Encoding: 7bit
Message-ID: VM2.mycompany.com-123456789
Sensitivity: Private
Importance: High
To: 2145551212@vm1.mycompany.com To: 「」 パーソンズ、グレン、W. 2145551234@VM1.mycompany.com From: 「ボードルイ、グレッグ」 2175552345@VM2.mycompany.com 日付: 月曜日、1993年8月26日の中部標準時10時20分20秒のMIMEバージョン: 1.0(声1.0)文書内容: 複合/音声メール。 境界は"MessageBoundary"満足している転送コード化と等しいです: 7はMessage IDに噛み付きました: VM2.mycompany.com-123456789感度: 個人的な重要性: 高値
--MessageBoundary
Content-type: Audio/32KADPCM
Content-Transfer-Encoding: Base-64
--MessageBoundary文書内容: 32KADPCMの満足している転送オーディオ/コード化: 基地-64
Vaudreuil Experimental [Page 20] RFC 1911 MIME Voice Profile February 1996
ボードルイの実験的な[20ページ]RFC1911は声のプロフィール1996年2月にまねます。
glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd
(This is a sample of the base-64 Spoken Name data) fgdhgd
jrgoij3o45itj09fiuvdkjgWlakgQ93ijkpokfpgokQ90gQ5tkjpokfgW
dlkgpokpeowrit09==
glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd(これはベース-64のSpoken Nameデータのサンプルである)fgdhgd jrgoij3o45itj09fiuvdkjgWlakgQ93ijkpokfpgokQ90gQ5tkjpokfgW dlkgpokpeowrit09=
--MessageBoundary
Content-type: Audio/32KADPCM
Content-Transfer-Encoding: Base-64
--MessageBoundary文書内容: 32KADPCMの満足している転送オーディオ/コード化: 基地-64
glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd
(This is a sample of the base-64 Spoken Subject data) fgdhgd
jrgoij3o45itj09fiuvdkjgWlakgQ93ijkpokfpgokQ90gQ5tkjpokfgW
dlkgpokpeowrit09==
glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd(これはベース-64のSpoken Subjectデータのサンプルである)fgdhgd jrgoij3o45itj09fiuvdkjgWlakgQ93ijkpokfpgokQ90gQ5tkjpokfgW dlkgpokpeowrit09=
--MessageBoundary
Content-type: Audio/32KADPCM
Content-Transfer-Encoding: Base-64
--MessageBoundary文書内容: 32KADPCMの満足している転送オーディオ/コード化: 基地-64
glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd
(This is a sample of the base-64 message data) fgdhgdfwgd
jrgoij3o45itj09fiuvdkjgWlakgQ93ijkpokfpgokQ90gQ5tkjpokfgW
dlkgpokpeowrit09==
glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd(これはベース-64のメッセージデータのサンプルである)fgdhgdfwgd jrgoij3o45itj09fiuvdkjgWlakgQ93ijkpokfpgokQ90gQ5tkjpokfgW dlkgpokpeowrit09=
--MessageBoundary--
--MessageBoundary--
13. Appendix - Audio/32KADPCM Content Type
13. 付録--オーディオ/32KADPCM content type
Mime type name: Audio
Mime Sub-Type name: 32KADPCM
Required Parameters: None
Optional Parameters: None
Encoding Considerations: Any encoding necessary for transport may be
used.
型名をまねてください: オーディオMime Sub-型名: 32KADPCMはパラメタを必要としました: なにも、任意のパラメタ: なにも、問題をコード化します: 輸送に必要などんなコード化も使用されるかもしれません。
CCITT Recommendation G.721 [G721] describes the algorithm recommended for conversion of a 64 KB/s A-law or u-law PCM channel to and from a 32 KB/s channel. The conversion is applied to the PCM stream using an Adaptive Differential Pulse Code Modulation (ADPCM) transcoding technique.
CCITT Recommendation G.721[G721]は64KB/sのA-法かu-法のPCMチャンネルの変換のためにチャンネルと32KB/sのチャンネルから推薦されたアルゴリズムを説明します。 変換は、Adaptive Differentialパルスコードの変調(ADPCM)コード変換のテクニックを使用することでPCMストリームに適用されます。
No header information shall be included before the audio data. When this subtype is present, a sample rate of 8000 Hz and a single channel is assumed.
オーディオデータの前にヘッダー情報を全く含んでいないものとします。 この「副-タイプ」が存在しているとき、8000Hzと単独のチャンネルの見本郵送料率は想定されます。
Vaudreuil Experimental [Page 21] RFC 1911 MIME Voice Profile February 1996
ボードルイの実験的な[21ページ]RFC1911は声のプロフィール1996年2月にまねます。
14. Appendix - Multipart/Voice-Message
14. 複合の、または、メッセージを声に出している付録
Mime type name: Multipart
Mime Sub-Type name: Voice-Message
Required Parameters: Boundary
Optional Parameters: None
Encoding Considerations: Binary of 7 bit are sufficient. Base-64
and Quoted-Printable are prohibited on multipart content-types.
型名をまねてください: 複合Mime Sub-型名: 音声メールはパラメタを必要としました: 境界の任意のパラメタ: なにも、問題をコード化します: 7ビットのバイナリーは十分です。 -64が基づいてQuoted印刷可能である、複合content typeでは、禁止されています。
The syntax of a Multipart/Voice-Message is identical to the Multipart/Mixed content type. The Voice-Message content-type contains three body parts. The first is an audio segment containing the spoken name of the originator, the second is an audio segment containing a spoken subject, and the third is the voice message itself. Forwarded voice messages can be created by simply nesting multipart content types.
声Multipart/メッセージの構文はMultipart/Mixed content typeと同じです。 Voiceメッセージ内容タイプは3つの身体の部分を含んでいます。 1番目は創始者の話された名前を含むオーディオセグメントです、そして、2番目は話された対象を含むオーディオセグメントです、そして、3番目は音声メール自体です。 単に複合content typeを入れ子にすることによって、転送された音声メールを作成できます。
The spoken name segment shall contain the name of the message sender in the voice of the sender. The length of the spoken name segment must not exceed 12 seconds. If no spoken name is available, the segment must still be present but may be empty.
セグメントという話された名前は送付者の声でメッセージ送付者の名前を含むものとします。 セグメントという話された名前の長さは12秒を超えてはいけません。 どんな話された名前も利用可能でないなら、セグメントは、まだ存在していなければなりませんが、空であるかもしれません。
The spoken subject segment shall contain the subject of the message sender in the voice of the sender. The length of the spoken subject segment must not exceed 20 seconds. If no spoken subject segment is available, the segment must still be present but may be empty.
話された対象のセグメントは送付者の声でメッセージ送付者の対象を含むものとします。 話された対象のセグメントの長さは20秒を超えてはいけません。 どんな話された対象のセグメントも利用可能でないなら、セグメントは、まだ存在していなければなりませんが、空であるかもしれません。
The voice message body part may contain any arbitrary content including a multipart/mixed collections of body parts, though will typically be an audio segment.
もっとも、身体の部分の複合の、または、複雑な収集を含んでいて、身体の部分がどんな任意の内容も含むかもしれないという音声メールは通常オーディオセグメントになるでしょう。
The default handling of the Multipart/Voice-Message shall be to voice the spoken-name segment and then the spoken-subject prior to displaying or voicing the remainder of the message.
声Multipart/メッセージのデフォルト取り扱いは、メッセージの残りを表示するか、または声に出す前に話された名前セグメントを声に出して、次に、話された対象を声に出すことでしょう。
Vaudreuil Experimental [Page 22]
ボードルイ実験的です。[22ページ]
一覧
スポンサーリンク
