RFC4416 日本語訳
4416 Goals for Internet Messaging to Support Diverse ServiceEnvironments. J. Wong, Ed.. February 2006. (Format: TXT=93676 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group J. Wong, Ed. Request for Comments: 4416 Nortel Networks Category: Informational February 2006
エド、ワーキンググループJ.ウォンをネットワークでつないでください。コメントのために以下を要求してください。 4416 ノーテルはカテゴリをネットワークでつなぎます: 情報の2006年2月
Goals for Internet Email to Support Diverse Service Environments
インターネットの目標は、さまざまのサービス環境を支持するためにメールされます。
Status of This Memo
このメモの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
Abstract
要約
This document is a history capturing the background, motivation and thinking during the LEMONADE definition and design process.
このドキュメントはLEMONADE定義とデザイン過程の間にバックグラウンド、動機、および考えを得る歴史です。
The LEMONADE Working Group -- Internet email to support diverse service environments -- is chartered to provide enhancements to Internet mail to facilitate its use by more diverse clients. In particular, by clients on hosts not only operating in environments with high latency/bandwidth-limited unreliable links but also constrained to limited resources. The enhanced mail must be backwards compatible with existing Internet mail.
LEMONADE作業部会(さまざまのサービス環境を支持するインターネットメール)は、よりさまざまのクライアントによる使用を容易にするために増進をインターネット・メールに提供するためにチャーターされます。 クライアントで限りある資源に帯域幅で高い潜在/限られた頼り無いリンクで環境で作動するだけではありませんが、また抑制されたホストで特定で。 高められたメールが後方に既存のインターネット・メールと互換性があった状態であるに違いありません。
The primary motivation for this effort is -- by making Internet mail protocols richer and more adaptable to varied media and environments -- to allow mobile handheld devices tetherless access to Internet mail using only IETF mail protocols.
この努力に関する第一の動機がインターネット・メールを様々なメディアと環境により豊かでより適合できるプロトコルにすることによって、あります--IETFメールプロトコルだけを使用することでインターネット・メールへの可動のハンドヘルドデバイスtetherlessアクセスを許すために。
The requirements for these devices drive a discussion of the possible protocol enhancements needed to support multimedia messaging on limited-capability hosts in diverse service environments. A list of general principles to guide the design of the enhanced messaging protocols is documented. Finally, additional issues of providing seamless service between enhanced Internet mail and the existing separate mobile messaging infrastructure are briefly listed.
これらの装置のための要件は限られた能力ホストの上でさまざまのサービス環境でマルチメディアメッセージングを支持するのに必要である可能なプロトコル増進の議論を追い立てます。 高められたメッセージング・プロトコルのデザインを誘導する綱領のリストは記録されます。 最終的に、高められたインターネット・メールと既存の別々の可動のメッセージングインフラストラクチャの間のシームレスのサービスを提供する追加設定は簡潔に記載されています。
Wong Informational [Page 1] RFC 4416 LEMONADE Goals February 2006
[1ページ]RFC4416レモネード目標2006年2月の情報のウォン
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions Used in This Document . . . . . . . . . . . . . . 6
3. Messaging Terminology and Simple Model (Client-to-Server
Aspect Only) . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Messaging Transaction Models . . . . . . . . . . . . . . . 6
3.2. Mobile Messaging Transactions . . . . . . . . . . . . . . 7
3.2.1. Submission . . . . . . . . . . . . . . . . . . . . . . 7
3.2.2. Notification . . . . . . . . . . . . . . . . . . . . . 7
3.2.3. Retrieval . . . . . . . . . . . . . . . . . . . . . . 8
4. Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Existing Profiles . . . . . . . . . . . . . . . . . . . . 8
4.1.1. Voice Messaging (VPIMv2) . . . . . . . . . . . . . . . 8
4.1.2. iFax . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1.3. Internet Voice Mail (IVM) . . . . . . . . . . . . . . 9
4.2. Putative Client Profiles . . . . . . . . . . . . . . . . . 9
4.2.1. TUI . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2.2. Multi-Modal Clients . . . . . . . . . . . . . . . . . 11
4.2.3. WUI . . . . . . . . . . . . . . . . . . . . . . . . . 11
5. General Principles . . . . . . . . . . . . . . . . . . . . . . 13
5.1. Protocol Conservation . . . . . . . . . . . . . . . . . . 13
5.1.1. Reuse Existing Protocols . . . . . . . . . . . . . . . 13
5.1.2. Maintain Existing Protocol Integrity . . . . . . . . . 13
5.2. Sensible Reception/Sending Context . . . . . . . . . . . . 13
5.2.1. Reception Context . . . . . . . . . . . . . . . . . . 13
5.2.2. Sending Context . . . . . . . . . . . . . . . . . . . 13
5.3. Internet Infrastructure Preservation . . . . . . . . . . . 14
5.4. Voice Requirements (Near Real-Time Delivery) . . . . . . . 14
5.5. Fax Requirements (Guaranteed Delivery) . . . . . . . . . . 14
5.6. Video Requirements (Scalable Message Size) . . . . . . . . 14
6. Issues and Requirements: TUI Subset of WUI . . . . . . . . . . 14
6.1. Requirements on the Message Retrieval Protocol . . . . . . 14
6.1.1. Performance Issues . . . . . . . . . . . . . . . . . . 15
6.1.2. Functional Issues . . . . . . . . . . . . . . . . . . 16
6.2. Requirements on the Message Submission Protocol . . . . . 18
6.2.1. Forward without Download Support . . . . . . . . . . . 18
6.2.2. Quota by Context Enforcement . . . . . . . . . . . . . 19
6.2.3. Future Delivery Support with Cancel . . . . . . . . . 19
6.2.4. Support for Committed Message Delivery . . . . . . . . 20
6.3. Requirements on Message Notification . . . . . . . . . . . 20
6.3.1. Additional Requirements on Message Notification . . . 21
7. Issues and Requirements: WUI Mobility Aspects . . . . . . . . 21
7.1. Wireless Considerations on Email . . . . . . . . . . . . . 21
7.1.1. Transport Considerations . . . . . . . . . . . . . . . 21
7.1.2. Handset-Resident Client Limitations . . . . . . . . . 22
7.1.3. Wireless Bandwidth and Network Utilization
Considerations . . . . . . . . . . . . . . . . . . . . 22
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 4 2。 コンベンションは本書では.6 3を使用しました。 用語と単純モデル(クライアントからサーバへの局面専用).63.1を通信させます。 メッセージング取引は.63.2をモデル化します。 モバイルメッセージング取引. . . . . . . . . . . . . . 7 3.2.1。 服従. . . . . . . . . . . . . . . . . . . . . . 7 3.2.2。 通知. . . . . . . . . . . . . . . . . . . . . 7 3.2.3。 検索. . . . . . . . . . . . . . . . . . . . . . 8 4。 プロフィール. . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.1。 既存のプロフィール. . . . . . . . . . . . . . . . . . . . 8 4.1.1。 メッセージング(VPIMv2). . . . . . . . . . . . . . . 8 4.1.2iFax. . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1.3を声に出してください。 インターネットボイスメール(IVM。). . . . . . . . . . . . . . 9 4.2 推定のクライアントプロフィール. . . . . . . . . . . . . . . . . 9 4.2.1。 ニュージーランド産蜜. . . . . . . . . . . . . . . . . . . . . . . . . 9 4.2.2。 マルチモーダルクライアント. . . . . . . . . . . . . . . . . 11 4.2.3。 WUI. . . . . . . . . . . . . . . . . . . . . . . . . 11 5。 綱領. . . . . . . . . . . . . . . . . . . . . . 13 5.1。 保護. . . . . . . . . . . . . . . . . . 13 5.1.1について議定書の中で述べてください。 既存のプロトコル. . . . . . . . . . . . . . . 13 5.1.2を再利用してください。 既存のプロトコル保全. . . . . . . . . 13 5.2を維持してください。 分別があるレセプション/発信文脈. . . . . . . . . . . . 13 5.2.1。 レセプション文脈. . . . . . . . . . . . . . . . . . 13 5.2.2。 文脈. . . . . . . . . . . . . . . . . . . 13 5.3を送ります。 インターネットインフラストラクチャ保存. . . . . . . . . . . 14 5.4。 要件(リアルタイムの配送における).145.5を声に出してください。 ファックスで、要件(荷渡しを保証する).145.6を送ってください。 ビデオ要件(スケーラブルなメッセージサイズ).146。 問題と要件: WUI. . . . . . . . . . 14 6.1のニュージーランド産蜜部分集合。 メッセージ検索プロトコル. . . . . . 14 6.1.1に関する要件。 パフォーマンスは.2に.156.1を発行します。 機能的な問題. . . . . . . . . . . . . . . . . . 16 6.2。 メッセージ服従プロトコル. . . . . 18 6.2.1に関する要件。 ダウンロードなしでサポート. . . . . . . . . . . 18 6.2.2を進めてください。 文脈実施. . . . . . . . . . . . . 19 6.2.3の割当て。 キャンセル. . . . . . . . . 19 6.2.4がある今後の配送サポート。 遂行されたメッセージには、配送. . . . . . . . 20 6.3を支持してください。 メッセージ通知. . . . . . . . . . . 20 6.3.1に関する要件。 メッセージ通知. . . 21 7に関する追加要件。 問題と要件: WUI移動性局面. . . . . . . . 21 7.1。 メール. . . . . . . . . . . . . 21 7.1.1に関する無線の問題。 問題. . . . . . . . . . . . . . . 21 7.1.2を輸送してください。 受話器居住者クライアント制限. . . . . . . . . 22 7.1.3。 無線の帯域幅とネットワーク利用問題. . . . . . . . . . . . . . . . . . . . 22
Wong Informational [Page 2] RFC 4416 LEMONADE Goals February 2006
[2ページ]RFC4416レモネード目標2006年2月の情報のウォン
7.1.4. Content Display Considerations . . . . . . . . . . . . 23
7.2. Requirements to Enable Wireless Device Support . . . . . . 24
7.2.1. Transport Requirements . . . . . . . . . . . . . . . . 24
7.2.2. Enhanced Mobile Email Functionality . . . . . . . . . 24
7.2.3. Client Requirements . . . . . . . . . . . . . . . . . 25
7.2.4. Bandwidth Requirements . . . . . . . . . . . . . . . . 25
7.2.5. Media Handling Requirements . . . . . . . . . . . . . 25
8. Interoperation with Existing Mobile Messaging . . . . . . . . 27
8.1. Addressing of Mobile Devices . . . . . . . . . . . . . . . 27
8.2. Push Model of Message Retrieval . . . . . . . . . . . . . 27
8.3. Message Notification . . . . . . . . . . . . . . . . . . . 27
8.4. Operator Issues . . . . . . . . . . . . . . . . . . . . . 27
8.4.1. Support for End-to-End Delivery Reports and
Message-Read Reports . . . . . . . . . . . . . . . . . 27
8.4.2. Support for Selective Downloading . . . . . . . . . . 27
8.4.3. Transactions and Operator Charging Units . . . . . . . 27
8.4.4. Network Authentication . . . . . . . . . . . . . . . . 28
8.5. LEMONADE and MMS . . . . . . . . . . . . . . . . . . . . . 28
9. Security Considerations . . . . . . . . . . . . . . . . . . . 32
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
10.1. Normative References . . . . . . . . . . . . . . . . . . . 32
10.2. Informative References . . . . . . . . . . . . . . . . . . 32
Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 37
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 38
Appendix C. IAB Note: Unified Notification Protocol
Considerations . . . . . . . . . . . . . . . . . . . 38
7.1.4. 満足している表示問題. . . . . . . . . . . . 23 7.2。 ワイヤレス機器サポート. . . . . . 24 7.2.1を可能にするという要件。 要件. . . . . . . . . . . . . . . . 24 7.2.2を輸送してください。 モバイルメールの機能性. . . . . . . . . 24 7.2.3を高めました。 クライアント要件. . . . . . . . . . . . . . . . . 25 7.2.4。 帯域幅要件. . . . . . . . . . . . . . . . 25 7.2.5。 要件. . . . . . . . . . . . . 25 8を扱うメディア。 既存のモバイルメッセージング. . . . . . . . 27 8.1があるInteroperation。 モバイル機器. . . . . . . . . . . . . . . 27 8.2のアドレシング。 メッセージ検索. . . . . . . . . . . . . 27 8.3のモデルを押してください。 メッセージ通知. . . . . . . . . . . . . . . . . . . 27 8.4。 オペレータは.1に.278.4を発行します。 終わりから終わりへの配送には、レポートとメッセージで読まれたレポート. . . . . . . . . . . . . . . . . 27 8.4.2を支持してください。 選択しているダウンロード. . . . . . . . . . 27 8.4.3のために、支持します。 取引とオペレータ充電ユニット. . . . . . . 27 8.4.4。 認証. . . . . . . . . . . . . . . . 28 8.5をネットワークでつないでください。 レモネードとMMS. . . . . . . . . . . . . . . . . . . . . 28 9。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 32 10。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 32 10.1。 引用規格. . . . . . . . . . . . . . . . . . . 32 10.2。 有益な参照. . . . . . . . . . . . . . . . . . 32付録A.貢献者. . . . . . . . . . . . . . . . . . . . 37付録B.承認. . . . . . . . . . . . . . . . . . 38付録C.IAB注意: 統一された通知プロトコル問題. . . . . . . . . . . . . . . . . . . 38
Wong Informational [Page 3] RFC 4416 LEMONADE Goals February 2006
[3ページ]RFC4416レモネード目標2006年2月の情報のウォン
1. Introduction
1. 序論
Historically, a number of separate electronic messaging systems originated and evolved independently supporting different messaging modes. For example:
多くの別々の電子メッセージ通信システムが、独自に異なったメッセージングモードを支持しながら、歴史的に、由来して、発展しました。 例えば:
o Internet mail systems ([4], [10], [25]) evolved to support
networked computers with messages consisting of rich text plus
attachments.
o Voice mail systems utilized a client with a telephone-based or an
answering machine style of user interface. The telephone network
was used for transport of recorded voice messages.
o Fax store-and-forward users interface with a fax machine using a
modified telephone-based interface. Fax machines use the
telephone network for transport of fax data via modems.
o SMS (Short Message Service) [58] enabled users to send short text
messages between their cellular phones using the SS7 call control
infrastructure ([60], [61], [63], [64], [65]) for transport.
o [10] インターネット・メールシステム([4]、[25])は、メッセージが豊かなテキストと付属から成っていてネットワーク・コンピュータをサポートするために発展しました。o Voiceメールシステムはaが電話ベースであることでのクライアントかユーザーインタフェースの留守番電話スタイルを利用しました。 電話網は録音された声メッセージの輸送に使用されました。oファックス店とフォワードユーザは変更された電話ベースのインタフェースを使用するファックス装置に接続します。 ファックス装置はファックスデータの輸送にモデムを通して電話網を使用します。o SMS(短いMessage Service)[58]は、ユーザがそれらの携帯電話の間に短いテキスト・メッセージを送るのをSS7呼び出しコントロールインフラストラクチャ([60]を使用することで可能にしました、[61]、[63]、[64]、輸送のための[65])。
In the recent past, IETF mail standards have evolved to support additional/merged functionality:
最近において、IETFメール規格は追加しているか合併している機能性を支持するために発展しました:
o With MIME ([5], [6], [7], [8], [9], [28]), Internet mail transport
was enhanced to carry any kind of digital data
o Internet mail protocols were extended and profiled by VPIM ([13],
[14], [15], [34]) and iFAX ([16], [17], [18], [19], [20], [21],
[23]) so that enabled voice mail systems and fax machines could
use the common email infrastructure to carry their messages over
the Internet as an alternative to the telephone network. These
enhancements were such that the user's experience of reliability,
security, and responsiveness was not diminished by transport over
the Internet.
o [23]) [6] [7] [8] [9] [28]) MIME([5]で、インターネット・メール輸送はどんな種類のディジタルデータoも運ぶために高められて、インターネットメールプロトコルが、VPIM([13]、[14]、[15]、[34])、およびiFAX([16]によって広げられて、輪郭を描かれました、[17]、[18]、[19]、[20]、[21]ということでした、そして、したがって、それはボイスメールシステムを可能にしました、そして、ファックス装置は電話網に代わる手段としてそれらのメッセージをインターネットに伝えるのに一般的なメールインフラストラクチャを使用するかもしれません。 これらの増進がそのようなものであったので、ユーザの信頼性、セキュリティ、および反応性の経験はインターネットの上の輸送で減少しませんでした。
These successes -- making Internet mail transport the common infrastructure supporting what were separate messaging universes -- have encouraged a new vision: to provide, over the Internet, a single infrastructure, mailbox, and set of protocols for a user to get, respond to, and manipulate all of his or her messages from a collection of clients with varying capabilities, operating in diverse environments ([46],[47]).
これらの成功(インターネット・メール輸送を別々であったことを支持する一般的なインフラストラクチャにします宇宙が通信する)は新しいビジョンを奨励しました: ユーザが得るインターネット、ただ一つのインフラストラクチャ、メールボックス、およびセットのプロトコルの上で提供するために、その人のメッセージについて異なった能力があるクライアントの収集から応じて、すべてを操ってください、さまざまの環境([46]([47]))で作動して
The LEMONADE effort -- Internet email to support diverse service environments -- realizes this vision further by enabling Internet mail support for mobile devices and facilitating its interoperability with the existing mobile messaging universe.
LEMONADEの努力(さまざまのサービス環境を支持するインターネットメール)は、より遠くにモバイル機器のインターネット・メールサポートを可能にして、既存の可動のメッセージング宇宙で相互運用性を容易にすることによってこのビジョンがわかります。
Wong Informational [Page 4] RFC 4416 LEMONADE Goals February 2006
[4ページ]RFC4416レモネード目標2006年2月の情報のウォン
In the recent past, the evolution of messaging standards for resource-limited mobile devices has been rapid:
最近において、リソースで限られたモバイル機器のメッセージング規格の発展は急速です:
o In the cellular space, SMS was enhanced to EMS (Extended Message
Service) [59] allowing longer text messages, images, and graphics.
With an even richer feature set, MMS (Multimedia Messaging
Service) ([43], [52], [53], [56], [57]) was developed as a
lightweight access mechanism for the transmission of pictures,
audio, and motion pictures. MMS protocols are based in part on
Internet standards (both messaging and web [24]) as well as SMS.
The cellular messaging universe is a separate infrastructure
adapted to deliver appropriate functionality in a timely and
effective manner to a special environment.
o As well, the number of different mobile clients that need to be
supported keeps proliferating. (e.g., besides cellular phones
there are wireless-enabled PDAs, tablet computers, etc.)
o セルスペースでは、SMSは、[59] より長いテキスト・メッセージ、イメージ、およびグラフィックスを許容しながら、EMS(拡張Message Service)に高められました。 [52] [53] [56] さらに豊かな特徴セット、MMS(マルチメディア・メッセージング・サービス)([43]で、[57])は絵、オーディオ、および映画の送信のための軽量のアクセス機構として開発されました。 MMSプロトコルはインターネット標準に一部基づいています。(SMSメッセージングとウェブ[24])とセルメッセージング宇宙の両方による. o As井戸、支持される必要がある異なった可動のクライアントの数を特別な環境へのタイムリーで効果的な方法による適切な機能性に送るために適合させられた別々のインフラストラクチャが増殖し続けるということです。 (例えば、携帯電話以外に、無線電信で可能にされたPDA、タブレットコンピュータなどがあります)
These resource-limited mobile devices are less powerful both in processing speed and display capabilities than conventional computers. They are also connected to the network by wireless links whose bandwidth and reliability are lower, latency is longer, and costs are higher than those of traditional wire-line links, hence the stress on the need to support adaptation to a whole different service environment.
これらのリソースで限られたモバイル機器は従来のコンピュータほど処理速度と表示能力で強力ではありません。 また、それらが帯域幅と信頼性が低い無線のリンクによってネットワークに接続されて、潜在が、より長く、コストはしたがって、伝統的なワイヤー・ラインのリンク、全体の異なったサービス環境への適合を支持する必要性における圧力のものより高いです。
This document collects a number the issues impeding Internet mail protocols from directly supporting the mobile service environment. Considerations arising from these issues are documented, and in some cases possible approaches to solutions are suggested. It turns out that the enhancements to support mobile clients also offer benefits for some terminals in other environments. In particular, the enhancements address the needs of the following diverse clients:
このドキュメントは数を集めます。インターネットを妨害する問題は直接モバイルサービス環境を支持するのからプロトコルを郵送します。 これらの問題から起こる問題は記録されます、そして、いくつかの場合、解決策への可能なアプローチは示されます。 また、可動のクライアントを支持する増進がいくつかの端末のために他の環境で利益を提供すると判明します。 特に、増進は以下のさまざまのクライアントの必要性を記述します:
o A wireless handheld device with an email client -- a Wireless User
Interface (WUI) mode of user interaction is dictated by the
constraints of the mobile wireless handheld operating environment.
o Telephone-based voice client -- a Telephone User Interface (TUI),
this is the user mode offered by a POTS set
* This is a subset of the WUI and is useful in other contexts.
o A multi-modal messaging client providing a coordinated messaging
session using display and audio modes simultaneously. (e.g., a
system consisting of a PC with a phone, or a wireless phone with
both a voice circuit and data channel requiring coordination).
* This is also a subset of the WUI and is useful in other
contexts.
o ユーザ相互作用のWireless User Interface(WUI)モードは変わりやすい無線電信ハンドヘルドの操作環境の規制で書き取られます。メールクライアントがいる無線のハンドヘルドデバイス--. o Telephoneベースの声のクライアント--Telephone User Interface(TUI)、これは、モードがPOTSセット*で部分集合を提供したWUIのユーザであり、同時に表示とオーディオモードを使用することで連携メッセージングセッションを提供しながら、他の文脈o Aマルチモーダルメッセージングクライアントで役に立ちます。 (例えば声のサーキットとデータ・チャンネルの両方がコーディネートを必要とすることで電話、または無線電話でPCから成るシステム。) * これは、また、WUIの部分集合であり、他の文脈で役に立ちます。
Wong Informational [Page 5] RFC 4416 LEMONADE Goals February 2006
[5ページ]RFC4416レモネード目標2006年2月の情報のウォン
The rest of this document is structured as follows:
このドキュメントの残りは以下の通り構造化されます:
o A brief survey of messaging profiles - both existing and proposed.
o A list of principles to be used to guide the design of Internet
Messaging for diverse service environments.
o Detailed discussion on enhancements to Internet mail protocols to
support WUIs.
o Some issues relating to the interoperation of enhanced Internet
mail and the existing mobile messaging services.
o メッセージングプロフィールの概略調査--存在していて、提案されて. さまざまのサービス環境インターネットメールプロトコルへの増進についてのo Detailed議論がWUIs o Someを支持するようにインターネットMessagingのデザインを誘導するのに使用されるべき原則のo Aリストは高められたインターネット・メールのinteroperationに関連して、既存のモバイルメッセージングサービスを支給します。
2. Conventions Used in This Document
2. 本書では使用されるコンベンション
This document refers generically to the sender of a message in the masculine (he/him/his) and to the recipient of the message in the feminine (she/her/hers). This convention is purely for convenience and makes no assumption about the gender of a message sender or recipient.
このドキュメントが一般的に男性のメッセージの送付者について言及する、(彼、/、彼、/、彼のもの)、女性のメッセージの受取人、(彼女、/、彼女の/、彼女のもの) このコンベンションは、メッセージ送付者か受取人の性に関して純粋に便宜のためにあって、仮定を全くしません。
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 RFC2119 [1].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[1]で説明されるように本書では解釈されることであるべきですか?
3. Messaging Terminology and Simple Model (Client-to-Server Aspect
Only)
3. メッセージング用語と単純モデル(クライアントからサーバへの局面専用)
In the client-server model prevalent in existing messaging architectures, the client, also known as a "user agent", presents messages to and accepts messages from the user. The server, also known as a "relay/server" or a "proxy-relay", provides storage and delivery of messages.
構造を通信させながら存在するのにおいて一般的なクライアント・サーバモデルでは、また、「ユーザエージェント」として知られているクライアントは、ユーザからメッセージを提示して、メッセージを受け入れます。 また、「リレー/サーバ」か「プロキシリレー」として知られているサーバはメッセージの格納と配送を提供します。
For a definitive description of Internet mail architecture, see [42].
インターネット・メール構造の決定的な記述に関しては、[42]を見てください。
3.1. Messaging Transaction Models
3.1. メッセージング取引モデル
There are two basic transactional models. In the "pull" model, the component, rather than the data flow, initiates the transaction. For example, a client may initiate a connection to a server and issue requests to the server to deliver incoming messages. Conventional email clients, web-mail clients, and WAP-based mobile clients use the "pull" model.
2つの基本的な取引のモデルがあります。 「牽引力」モデルで、コンポーネントは取引をデータフローよりむしろ開始します。 例えば、クライアントは、入力メッセージを送るためにサーバとの接続とサーバへの問題要求を開始するかもしれません。 従来のメールクライアント、Webメールクライアント、およびWAPベースの可動のクライアントは「牽引力」モデルを使用します。
The "push" model differs in that the component initiating the
transaction does so because of some data flow affecting it. For
example, the arrival of a new message at the terminating server may
cause a notification to be sent ("pushed") to a messaging client.
「プッシュ」モデルはトランザクションを開始するコンポーネントがそれに影響する何らかのデータフローのためにそうするという点において異なります。 例えば、終わりサーバにおける新しいメッセージの到着で、メッセージングクライアントに通知を送るかもしれません(「押されます」)。
Wong Informational [Page 6] RFC 4416 LEMONADE Goals February 2006
[6ページ]RFC4416レモネード目標2006年2月の情報のウォン
3.2. Mobile Messaging Transactions
3.2. モバイルメッセージングトランザクション
The most common functions are: "submission", "notification", and "retrieval". There may be other functions, such as "delivery reports", "read-reply reports", "forwarding", "view mailbox", "store message", etc. Each of these transactions can be implemented in either a pull or push model. However, some transactions are more naturally suited to one model or another.
最も一般的な機能は以下の通りです。 「服従」、「通知」、および「検索。」 「配送レポート」、「回答を読んでいるレポート」、「推進」、「視点メールボックス」、「店からのメッセージ」などの他の機能があるかもしれません。 牽引力かプッシュモデルのどちらかでそれぞれのこれらのトランザクションを実装することができます。 しかしながら、いくつかのトランザクションが、より自然に何らかのモデルに合っています。
The following figure depicts a simple client-server model (no server- to-server interactions are shown):
以下の図は簡単なクライアント・サーバモデルについて表現します(サーバへのサーバ相互作用は全く示されません):
(1) Message submission
(2) Message notification
(3) & (4) Message retrieval
(1) メッセージ服従(2)メッセージ通知(3)と(4)メッセージ検索
+-------+ +------+ +-------+
|Mail |-------(1)------>| |-----------(2)-------->|Mail |
|Client | Submit msg | | Notification /|Client |
+-------+ | | / +--+----+
| | / ^
| |<----------(3)-----+ /
|Server| Retrieval request /
| | /
| | /
| |-----------(4)-------+
| | Retrieval response
| |
+------+
+-------+ +------+ +-------+ |メール|-------(1)------>| |-----------(2)-------->|メール| |クライアント| msgを提出してください。| | 通知/|クライアント| +-------+ | | / +--+----+ | | / ^ | | <、-、-、-、-、-、-、-、-、--(3)-----+ / |サーバ| 検索要求/| | / | | / | |-----------(4)-------+ | | 検索応答| | +------+
Simple Messaging Model
簡単なメッセージングモデル
3.2.1. Submission
3.2.1. 服従
"Submission" is the transaction between a client and a server by which the user of the former sends a new message to another user. Submission is a push from client to server.
「服従」は前者のユーザが新しいメッセージを別のユーザに送るクライアントとサーバの間のトランザクションです。 クライアントからサーバまで服従はプッシュです。
3.2.2. Notification
3.2.2. 通知
"Notification" is the transaction by which the server notifies the client that it has received messages intended for that client. Notification is a push from server to client.
「通知」はサーバがそのクライアントのために意図するメッセージを受け取ったことをクライアントに通知するトランザクションです。 サーバからクライアントまで通知はプッシュです。
Wong Informational [Page 7] RFC 4416 LEMONADE Goals February 2006
[7ページ]RFC4416レモネード目標2006年2月の情報のウォン
All the larger mobile messaging systems implement a push model for the notification because data can be presented to the user without the user's experiencing network/transport latencies, and without tying up network resources for polling when there is no new data.
すべての、より大きいモバイルメッセージシステムが、どんな新しいデータもないときユーザがネットワーク/輸送潜在を経験して、世論調査のためのネットワーク資源をタイアップしないでユーザにデータを提示できるので、通知のためにプッシュモデルを実装します。
Internet mail differs in that it has not yet seen the need for a standardized notification protocol.
インターネット・メールは標準化された通知プロトコルに関してまだ必要性を認めていないという点において異なります。
3.2.3. Retrieval
3.2.3. 検索
"Retrieval" is the transaction between a client and a server by which the client can obtain one or more messages from the server. Retrieval can be push or pull.
「検索」はクライアントがサーバから1つ以上のメッセージを得ることができるクライアントとサーバの間のトランザクションです。検索は、プッシュであるか引かれることができます。
Implemented in some mobile systems as an option, the push model has the advantage that the user is not necessarily aware of transport or network latencies.
オプションとしていくつかのモバイルシステムで実装されます、プッシュモデルには、ユーザが必ずそうであるというわけではない利点が輸送かネットワーク潜在を意識していた状態であります。
The pull model, implemented in most systems (mobile or conventional), has the advantage that the user can control what data is actually sent to and stored by the client.
ほとんどのシステム(モバイルの、または、従来の)で実装された牽引力のモデルはデータが実際に何に送られるかを制御して、クライアントによって保存されて、ユーザがそうすることができる利点を持っています。
4. Profiles
4. プロフィール
Internet messaging can be made to support a variety of client and server types other than traditional email. The clients may be adapted for host restrictions such as limited processing power, message store, display window size, etc. Alternatively, clients may be adapted for different functionality (e.g., voice mail, fax, etc.). Servers may support optional mail features that would allow better handling of different media (e.g., voice mail, fax, video, etc.). A number of Internet mail profiles supporting specific application niches have been defined or proposed.
インターネットメッセージングにさまざまなクライアントとサーバが伝統的なメール以外のタイプであるとサポートさせることができます。 クライアントは限られた処理能力、メッセージ店、ディスプレイ・ウィンドウサイズなどのホスト制限のために適合させられるかもしれません。 あるいはまた、クライアントは異なった機能性(例えば、ボイスメール、ファックスなど)のために適合させられるかもしれません。 サーバは、任意のメールが異なったメディア(例えば、ボイスメール、ファックス、ビデオなど)の、より良い取り扱いを許す特徴であるとサポートするかもしれません。 特定のアプリケーションが適所であるとサポートする多くのインターネット・メールプロフィールが、定義されるか、または提案されました。
4.1. Existing Profiles
4.1. 既存のプロフィール
The following are examples of server-to-server profiles of SMTP and MIME. Except for IVM, they do not address client-to-server interactions.
↓これはサーバからサーバへのSMTPとMIMEのプロフィールに関する例です。 IVM以外に、彼らはクライアントからサーバへの相互作用を扱いません。
4.1.1. Voice Messaging (VPIMv2)
4.1.1. 声のメッセージング(VPIMv2)
These profiles, RFC3801 [13] to RFC3803 [15], enable the transport of voice messages using the Internet mail system. The main driver for this work was support of IP transport for voice mail systems. As voice mail clients are accustomed to a higher degree of responsiveness and certainty as to message delivery, the functionality added by VPIMv2 includes Message Disposition
これらのプロフィール(RFC3803[15]へのRFC3801[13])は、インターネット・メールシステムを使用することで音声メールの輸送を可能にします。 この仕事のための主なドライバーはボイスメールシステムのためのIP輸送のサポートでした。ボイスメールクライアントがメッセージ配送に関して、より高度合いの反応性と確実性に慣れているとき、VPIMv2によって加えられた機能性はMessage Dispositionを含んでいます。
Wong Informational [Page 8] RFC 4416 LEMONADE Goals February 2006
[8ページ]RFC4416レモネード目標2006年2月の情報のウォン
Notification and Delivery Status Message ([12], [3]). Voice media has also been added to multi-part message bodies.
通知と配送ステータスメッセージ([12]、[3])。 また、声のメディアは複合メッセージ本体に加えられます。
4.1.2. iFax
4.1.2. iFax
This set of profiles ([16], [17], [18], [19], [20], [21]) enables the transport of fax using Internet mail protocols. This work defined the image/tiff MIME type. Support for fax clients also required extensions to Message Delivery Notification.
[17] [18] [19] [20] このセットのプロフィール([16]であり、[21])は、インターネットメールプロトコルを使用することでファックスの輸送を可能にします。 この仕事はイメージ/いさかいMIMEの種類を定義しました。 また、ファックスクライアントのサポートはMessage Delivery Notificationに拡大を必要としました。
4.1.3. Internet Voice Mail (IVM) [34]
4.1.3. インターネットボイスメール(IVM)[34]
This proposed mail enhancement (whose requirements are described in RFC 3773 [30]) targets support for the interchange of voice messaging between the diverse components (clients as well as servers) in systems supporting voice mail.
これはメール増進を提案しました。(要件が目標が声の置き換えのためにサポートするRFC3773[30])でボイスメールをサポートしながらシステムのさまざまのコンポーネント(サーバと同様にクライアント)の間で通信すると説明される。
4.2. Putative Client Profiles
4.2. 推定のクライアントプロフィール
4.2.1. TUI
4.2.1. ニュージーランド産蜜
It is desirable to replace proprietary protocols between telephone user interface clients and message stores with standards-based interfaces. The proprietary protocols were created to provide media- aware capabilities as well as to provide the low-latency required by some messaging applications.
電話ユーザーインタフェースクライアントとメッセージ店の間で固有のプロトコルを規格ベースのインタフェースに取り替えるのは望ましいです。 固有のプロトコルは、意識している能力をメディアに提供して、いくつかのメッセージングアプリケーションで必要である低遅延を提供するために作成されました。
An example of a TUI client is a voice mail client. Because a POTS phone lacks any intelligence, the voice mail client functionality has to be provided by a user agent networked to the mail server. The main architectural difference between a conventional voice mail system and an Internet messaging system supporting a TUI is that the voice mail system uses a specialized message store and protocols.
TUIクライアントの例はボイスメールクライアントです。 POTS電話がどんな知性も欠いているので、ボイスメールクライアントの機能性はメールサーバにネットワークでつながれたユーザエージェントによって提供されなければなりません。従来のボイスメールシステムとTUIをサポートするインターネットメッセージシステムの主な建築違いはボイスメールシステムが専門化しているメッセージ店とプロトコルを使用するということです。
The following figure depicts the architecture of current voice mail systems implementing VPIMv2:
以下の図はVPIMv2を実装する現在のボイスメールシステムのアーキテクチャについて表現します:
Wong Informational [Page 9] RFC 4416 LEMONADE Goals February 2006
[9ページ]RFC4416レモネード目標2006年2月の情報のウォン
|-------------|
|-------| RFC-822/MIME | |
| | |---------------------------| MTA |
| | | mail submission -> | |(E)SMTP
Telephone--|TUI|TUA| |------| |-----to
| | | Proprietary Protocol | | |another
| | |---------------------------| MS | | email
|-------| < - mail retrieval | | | server
|-------------|
mail client email server
|-------------| |-------| RFC-822/MIME| | | | |---------------------------| MTA| | | | メール提案->。| |(E)SMTPは電話をします--|ニュージーランド産蜜|トゥーア| |------| |-----to| | | 固有のプロトコル| | |別| | |---------------------------| さん| | メール|-------| <--メール検索| | | サーバ|-------------| メールクライアントEメールサーバ
|----------------voice messaging system -------------|
|----------------声のメッセージシステム-------------|
Mail client consists of: TUI (Telephone User Interface) and
TUA (Telephone User Agent)
メールクライアントは以下から成ります。 ニュージーランド産蜜(電話ユーザーインタフェース)とTUA(電話ユーザエージェント)
Communication between TUI and TUA is proprietary.
TUIとTUAとのコミュニケーションは独占です。
Email server consists of: MS (Mail Store) and
MTA (Message Transfer Agent)
Eメールサーバは以下から成ります。 MS(ストアを郵送する)とMTA(メッセージ転送エージェント)
Communication between MS and MTA is proprietary.
MSとMTAとのコミュニケーションは独占です。
It is proposed that the Proprietary Protocol be replaced with an IETF standard protocol:
ProprietaryプロトコルがIETF標準プロトコルに取り替えられるよう提案されます:
|-------------|
|-------| RFC-822/MIME | |
| | |---------------------------| MTA |
| | | mail submission -> | |(E)SMTP
Telephone--|TUI|TUA| |------| |-----to
| | | IETF protocol | | |another
| | |---------------------------| MS | | mail
|-------| <- mail retrieval | | | server
|-------------|
mail client email server
|-------------| |-------| RFC-822/MIME| | | | |---------------------------| MTA| | | | メール提案->。| |(E)SMTPは電話をします--|ニュージーランド産蜜|トゥーア| |------| |-----to| | | IETFプロトコル| | |別| | |---------------------------| さん| | メール|-------| <。 メール検索| | | サーバ|-------------| メールクライアントEメールサーバ
|- voice mail system-| |-mail server-|
|、-、ボイスメールシステム| |-メールサーバ|
Mail client consists of: TUI (Telephone User Interface) and
TUA (Telephone User Agent)
メールクライアントは以下から成ります。 ニュージーランド産蜜(電話ユーザーインタフェース)とTUA(電話ユーザエージェント)
Communication between TUI and TUA is proprietary.
TUIとTUAとのコミュニケーションは独占です。
Email server consists of: MS (Mail Store) and
MTA (Message Transfer Agent)
Eメールサーバは以下から成ります。 MS(ストアを郵送する)とMTA(メッセージ転送エージェント)
Communication between MS and MTA is proprietary.
MSとMTAとのコミュニケーションは独占です。
Wong Informational [Page 10] RFC 4416 LEMONADE Goals February 2006
[10ページ]RFC4416レモネード目標2006年2月の情報のウォン
4.2.2. Multi-Modal Clients
4.2.2. マルチモーダルクライアント
Multi-modal clients offer the advantage of coordinated voice and data modes of user interaction. Architecturally, the multi-modal client can be considered the union two user agent components -- one a TUI client, the other a simple GUI client. See the next figure. The Graphical User Agent (GUA) helps maintain the text display while the Telephone User Agent (TUA) acts on behalf of the TUI functionality.
マルチモーダルクライアントは連携声の利点とユーザ相互作用のデータモードを示します。 建築上、組合であるとマルチモーダルクライアントを考えることができます。2つのユーザエージェントコンポーネント--あるa TUIクライアント(もう片方のa純真なGUIクライアント)。 次の図を参照してください。 Graphical Userエージェント(GUA)は、Telephone Userエージェント(TUA)がTUIの機能性を代表して行動している間、テキストディスプレイを維持するのを助けます。
This model is the norm with cellular devices supporting data access because historically they evolved from cell phones to which a data channel was added. The presentation of multiple complementary modes of interaction gives end-users their choice of the most convenient and natural working mode for a particular task. There are other situations where a multi-modal model is appropriate. (For example, a telephone sales unit needs to provide a voice (telephone) mode and conventional desktop PC mode of interaction at the same time in an integrated manner.)
このモデルはセルデバイスが、データ・チャンネルが加えられた携帯電話から歴史的に発展したのでデータがアクセスであるとサポートしている標準です。 相互作用の複数の補足的なモードのプレゼンテーションは特定のタスクのために彼らの最も便利で自然な働くモードの選択をエンドユーザに与えます。 他の状況がマルチモーダルモデルが適切であるところにあります。 (例えば、電話営業部は、同時に統合方法で相互作用の声(電話)のモードと従来のデスクトップパソコンモードを提供する必要があります。)
A major issue in the design of multi-modal clients -- the need to synchronize the component user agents making up a client -- is only addressed by LEMONADE to a limited extent in Section 6.3.
マルチモーダルクライアントのデザインにおける主要な問題(クライアントを作るコンポーネントユーザエージェントを連動させる必要性)は限られた程度でセクション6.3でLEMONADEによって扱われるだけです。
4.2.3. WUI
4.2.3. WUI
The Wireless User Interface is functionally equivalent to a conventional email client on a personal workstation, but is optimized for clients on handheld tetherless devices. Factors needing consideration include limited memory and processing power. Limited bandwidth is also relatively high cost. As already alluded to above, in many cases (e.g., cellular devices), the mobile client is multi-modal. So WUIs can be modeled as resource-and-link-limited multi-modal clients.
Wireless User Interfaceはパーソナルワークステーションの上で従来のメールクライアントにとって機能上同等ですが、クライアントのためにハンドヘルドのtetherlessデバイスで最適化されます。 考慮を必要とする要素が限られたメモリと処理能力を含んでいます。 また、株式会社帯域幅は比較的高い費用です。 既に暗示されるように、多くの場合(例えば、セルデバイス)におけるモバイルクライアントの上に、マルチモーダルがあります。 それで、リソースと制限されたリンクマルチモーダルクライアントとしてWUIsをモデル化できます。
These terminals require the use of protocols that minimize the number of over-the-air transactions and reduce the amount of data that need be transmitted over the air overall. Such reduction in over-the-air transmission is a combination of more efficient protocol interaction and richer message presentation choices, whereby a user may more intelligently select what should be downloaded and what should remain on the server.
そして、これらの端末が数を最小にするプロトコルの使用を必要とする、過剰、空気、トランザクション、全体的に見て空気の上に伝えられなければならないデータ量を減少させてください。 中のそのような減少、過剰、空気伝播、 より効率的なプロトコル相互作用と、より豊かなメッセージプレゼンテーション選択の組み合わせはそうです。(ユーザは何をダウンロードするべきであるか、そして、何がサーバに残るべきであるかをより知的に選択で選択するかもしれません)。
Although not an explicit goal, providing equivalent or superior functionality to the wireless MMS service [43] (as defined by 3GPP, 3GPP2, and the OMA) is desirable.
明確な目標ではありませんが、ワイヤレスのMMSサービス[43](3GPP、3GPP2、およびOMAによって定義されるように)に同等であるか優れた機能性を提供するのは望ましいです。
Wong Informational [Page 11] RFC 4416 LEMONADE Goals February 2006
[11ページ]RFC4416レモネード目標2006年2月の情報のウォン
Proposed Wireless User Interface (WUI)/Multi-modal Clients
提案されたワイヤレスユーザインタフェース(WUI)/マルチモーダルクライアント
|wireless GUI client| email server
| ワイヤレスのGUIクライアント| Eメールサーバ
(E)SMTP (client-server) |-------------|
|-------| RFC-822/MIME | |
| | |---------------------------| |
| | | mail submission -> | |(E)SMTP
-|GUI|GUA| | |-----to
| | | | IETF standard protocol |------------ |another
| | | |----------------------------to MS below| | mail
| |-------| <- mail retrieval |------------ | server
| | | |
Handheld | | | |
Device WUI | | MTA |
| | | |
| | | |
| |-------| RFC-822/MIME | |
| | | |---------------------------| |
| | | | mail submission -> | |
-|TUI|TUA| |------| |
| | | IETF standard protocol | | |
| | |---------------------------| MS | |
|-------| <- mail retrieval | | |
|-------------|
TUI client voice mail server
(E) SMTP(クライアント/サーバ)|-------------| |-------| RFC-822/MIME| | | | |---------------------------| | | | | メール提案->。| |(E)SMTP、-|クイ|グァ| | |-----to| | | | IETF標準プロトコル|------------ |別| | | |----------------------------以下のMSに| | メール| |-------| <。 メール検索|------------ | サーバ| | | | ハンドヘルド| | | | デバイスWUI| | MTA| | | | | | | | | | |-------| RFC-822/MIME| | | | | |---------------------------| | | | | | メール提案->。| | -|ニュージーランド産蜜|トゥーア| |------| | | | | IETF標準プロトコル| | | | | |---------------------------| さん| | |-------| <。 メール検索| | | |-------------| TUIクライアントボイスメールサーバ
|----------------voice messaging system ----------------|
|----------------声のメッセージシステム----------------|
|------WUI-----| |---mail server---|
|------WUI-----| |---メールサーバ---|
Wireless GUI client consists of: GUI (Graphical User Interface) and
GUA (Graphical User Agent)
ワイヤレスのGUIクライアントは以下から成ります。 GUI(グラフィカルユーザインタフェイス)とGUA(グラフィカルなユーザエージェント)
Communication between UI and UA is proprietary.
UIとUAとのコミュニケーションは独占です。
TUI client consists of: TUI (Telephone User Interface) and
TUA (Telephone User Agent)
TUIクライアントは以下から成ります。 ニュージーランド産蜜(電話ユーザーインタフェース)とTUA(電話ユーザエージェント)
Communication between TUI and TUA is proprietary.
Communication between GUA and TUA is proprietary.
TUIとTUAとのコミュニケーションは独占です。 GUAとTUAとのコミュニケーションは独占です。
Mail (email and voice mail) server consists of:
MS (Mail Store) and
MTA (Message Transfer Agent)
メール(メールとボイスメール)サーバは以下から成ります。 MS(ストアを郵送する)とMTA(メッセージ転送エージェント)
Communication between MS and MTA is proprietary.
MSとMTAとのコミュニケーションは独占です。
Wong Informational [Page 12] RFC 4416 LEMONADE Goals February 2006
[12ページ]RFC4416レモネード目標2006年2月の情報のウォン
5. General Principles
5. 綱領
This is a list of principles to guide the design of extensions for Internet Messaging systems and protocols to support diverse endpoints.
これはインターネットMessagingシステムとプロトコルがさまざまの終点をサポートするように拡大のデザインを誘導する原則のリストです。
5.1. Protocol Conservation
5.1. プロトコル保護
5.1.1. Reuse Existing Protocols
5.1.1. 既存のプロトコルを再利用してください。
To the extent feasible, the enhanced messaging framework SHOULD use existing protocols whenever possible.
可能であるときはいつも、可能な範囲まで、高められたメッセージングフレームワークSHOULDは既存のプロトコルを使用します。
5.1.2. Maintain Existing Protocol Integrity
5.1.2. 既存のプロトコル保全を維持してください。
In meeting the requirement "Reuse Existing Protocols" (Section 5.1.1), the enhanced messaging framework MUST NOT redefine the semantics of an existing protocol.
「再利用の既存のプロトコル」(セクション5.1.1)という必要条件を満たすには、高められたメッセージングフレームワークは既存のプロトコルの意味論を再定義してはいけません。
Extensions, based on capability declaration by the server, will be used to introduce new functionality where required.
サーバで能力宣言に基づく拡張子は、必要であるところで新しい機能性を紹介するのに使用されるでしょう。
Said differently, we will not break existing protocols.
異なって言われていて、私たちは既存のプロトコルを破るつもりではありません。
5.2. Sensible Reception/Sending Context
5.2. 分別があるレセプション/発信文脈
5.2.1. Reception Context
5.2.1. レセプション文脈
When the user receives a message, that message SHOULD receive the treatment expected by the sender. For example, if the sender believes he is sending a voice message, voice message semantics should prevail to the extent that the receiving client can support such treatment.
ユーザがメッセージを受け取るとき、そのメッセージSHOULDは送付者によって予想された処理を受けます。 例えば、送付者が、彼が音声メールを送ると信じているなら、音声メール意味論は受信クライアントがそのような処理をサポートすることができるという範囲に広がるべきです。
5.2.2. Sending Context
5.2.2. 送付文脈
When the user sends a message, he SHOULD be able to specify the message context. That is, whether the network should treat the message as an text message, voice message, video message, etc. Again, this can only be complied with to the extent that the infrastructure and receiving client can provide such treatment. In practice, this would imply that the message should be in the form desired by the sender up to delivery to the receiving client.
ユーザが発信するとき、aは通信して、彼はSHOULDです。メッセージの文脈を指定できてください。 すなわち、ネットワークがテキストメッセージとしてメッセージを扱うべきであるか否かに関係なく、音声メール、ビデオメッセージですなど。 一方、これにインフラストラクチャと受信クライアントがそのような処理を提供できるという範囲まで従うことができるだけです。 実際には、これは、メッセージが送付者によって受信クライアントに配送まで望まれていたフォームにあるべきであるのを含意するでしょう。
Wong Informational [Page 13] RFC 4416 LEMONADE Goals February 2006
[13ページ]RFC4416レモネード目標2006年2月の情報のウォン
5.3. Internet Infrastructure Preservation
5.3. インターネットインフラストラクチャ保存
The infrastructure SHOULD change only where required for new functionality. Existing functionality MUST be preserved on the existing infrastructure; that is, all extensions must be backward compatible to allow for the gradual introduction of the enhancements. Messages created in an enhanced messaging context MUST NOT require changes to existing mail clients. However, there may be a degradation in functionality in certain circumstances.
インフラストラクチャSHOULDは新しい機能性に必要であるだけであるところで変化します。 既存のインフラストラクチャに既存の機能性を保存しなければなりません。 すなわちすべての拡大が増進のゆるやかな導入を考慮するのにおいて互換性があった状態で後方であるに違いありません。 高められたメッセージング文脈で作成されたメッセージは既存のメールクライアントへの変化を必要としてはいけません。 しかしながら、機能性における退行がある特定の状況ではあるかもしれません。
The enhanced messaging framework MUST be able to handle messages created in a non-enhanced messaging context; for example, a simple, RFC822 [2] text message.
高められたメッセージングフレームワークは非高められたメッセージング文脈で作成されたメッセージを扱うことができなければなりません。 例えば、簡単なRFC822[2]テキストメッセージ。
5.4. Voice Requirements (Near Real-Time Delivery)
5.4. 声の要件(近いリアルタイムの配送)
On the retrieval side, there are significant real-time requirements for retrieving a message for voice playback. More than any other media type, including video, voice is extremely sensitive to variations in playback latency. The enhanced messaging framework MUST address the real-time needs of voice.
検索側に、声の再生へのメッセージを検索するための重要なリアルタイムの要件があります。 ビデオを含むタイプが声に出すいかなる他のメディア以上も再生潜在の変化に非常に敏感です。 高められたメッセージングフレームワークは声のリアルタイムの必要性を扱わなければなりません。
5.5. Fax Requirements (Guaranteed Delivery)
5.5. ファックス要件(保証された配送)
Fax users have a particular expectation that is a challenge for enhanced Internet messaging. A person who sends a fax expects the recipient to receive the fax upon successful transmission. This clearly is not the case for Internet Mail.
ファックスユーザには、高められたインターネットメッセージングのための挑戦である特定の期待があります。 ファックスを送信する人は、受取人がうまくいっているトランスミッションのときにファックスを受け取ると予想します。 これは明確にインターネットメールのためのそうではありません。
Addressing this need is not in the scope of LEMONADE.
この必要性を扱うのがLEMONADEの範囲にありません。
5.6. Video Requirements (Scalable Message Size)
5.6. ビデオ要件(スケーラブルなメッセージサイズ)
Video mail has one outstanding feature: Video messages are potentially large! The enhanced messaging framework MUST scale for very large messages. Streaming from the server to the client, in both directions, MUST be supported.
ビデオメールには、1つの傑出している特徴があります: ビデオメッセージは潜在的に大きいです! 高められたメッセージングフレームワークは非常に大きいメッセージのために比例しなければなりません。 サーバからクライアントまで両方の方向に流れるのをサポートしなければなりません。
6. Issues and Requirements: TUI Subset of WUI
6. 問題と要件: WUIのニュージーランド産蜜部分集合
6.1. Requirements on the Message Retrieval Protocol
6.1. メッセージ検索プロトコルに関する要件
IMAP [10] is the Internet protocol for rich message retrieval and manipulation. The project MUST limit itself to extending IMAP where necessary and MUST not create a new protocol.
IMAP[10]は豊かなメッセージ検索と操作のためのインターネットプロトコルです。 プロジェクトは、それ自体を必要であるところでIMAPを広げるのに制限しなければならなくて、新しいプロトコルを作成してはいけません。
Wong Informational [Page 14] RFC 4416 LEMONADE Goals February 2006
[14ページ]RFC4416レモネード目標2006年2月の情報のウォン
6.1.1. Performance Issues
6.1.1. パフォーマンス問題
6.1.1.1. Real-Time Playback
6.1.1.1. リアルタイムの再生
The real-time playback of a voice message MUST be supported so that the user experience does not differ noticeably from that of a conventional voice messaging system.
音声メールのリアルタイムの再生をサポートしなければならないので、ユーザー・エクスペリエンスは従来の声のメッセージシステムのものと顕著に異なりません。
Possible solutions for this include making use of the existing incremental download capability of the IMAP protocol, or utilizing a companion streaming protocol.
これのための可能なソリューションは、存在の使用をIMAPプロトコルの増加のダウンロード能力にするか、または仲間のストリーミングのプロトコルを利用するのを含んでいます。
The IMAP protocol itself does not provide streaming by the strict definition of the term. It does provide for the incremental download of content in blocks. Most IMAP clients do not support this behavior and instead download the entire contents into a temporary file to be passed to the application.
IMAPプロトコル自体は用語の厳しい定義でストリーミングを提供しません。 それはブロックでの内容の増加のダウンロードに備えます。 ほとんどのIMAPクライアントは、この振舞いをサポートして、アプリケーションに通過されるために代わりに全体のコンテンツを一時ファイルにダウンロードしません。
There are several approaches to achieve real-time playback. The first approach is to implement an IMAP client that can pass data incrementally to the application as it is received from the network. The application can then read bytes from the network as needed to maintain a play buffer. Thus, it would not require the full download of contents. This approach may require server-side development to support partial download efficiently (i.e., to avoid re-opening files and positioning to the requested location).
リアルタイムの再生を達成するために、いくつかのアプローチがあります。 最初のアプローチはネットワークからそれを受け取るのに応じてデータをアプリケーションに増加して通過できるIMAPクライアントを実装することです。 そして、アプリケーションは、プレーバッファを維持するために必要に応じてネットワークからバイトを読むことができます。 したがって、それはコンテンツの完全なダウンロードを必要としないでしょう。 このアプローチは、効率的(すなわち、要求された位置へのファイルと位置決めを再開させるのを避ける)に部分的なダウンロードをサポートするためにサーバサイド開発を必要とするかもしれません。
Alternatively, the client can use the proposed IMAP channel extension [32] to request that the server make the selected content available via an alternate transport mechanism. A client can then ask the server to make the voice data available to the client via a streaming media protocol such as RTSP. This requires support on the client and server of a common streaming protocol.
あるいはまた、クライアントは、サーバで選択された内容が代替の移送機構で利用可能になるよう要求するのに提案されたIMAPチャンネル拡張子[32]を使用できます。 そして、クライアントは、声のデータをクライアントにとってRTSPなどのストリーミング・メディアプロトコルで利用可能にするようにサーバに頼むことができます。 これは一般的なストリーミングのプロトコルのクライアントとサーバで支持を要します。
6.1.1.2. Avoid Content-Transfer-Encoding Data Inflation
6.1.1.2. 満足している転送コード化データインフレーションを避けてください。
Another important performance optimization is enabling the transport of data using more efficient native coding rather than text-like content-transfer encodings such as "base 64".
別の重要なパフォーマンスの最適化は、「64インチを基礎づけます」のようなテキストのような満足している転送encodingsよりむしろさらに効率的なネイティブのコード化を使用することでデータの輸送を可能にしています。
Standard IMAP4 uses a text-based data representation scheme where all data is represented in a form that looks like text; that is, voice data must be encoded using "base 64" into a transport encoding that adds 30% to the size of a message. Downloading or appending large messages to the server already uses substantial bandwidth.
すべてのデータがテキストに似ているフォームに表されるところで標準のIMAP4はテキストベースのデータ表現体系を使用します。 すなわち、声のデータは「それをコード化すると加える輸送への64インチをメッセージのサイズに30%基礎づけてください」という使用することでコード化されて、ことであるに違いありません。 大きいメッセージをサーバにダウンロードするか、または追加すると、かなりの帯域幅が既に使用されます。
Wong Informational [Page 15] RFC 4416 LEMONADE Goals February 2006
[15ページ]RFC4416レモネード目標2006年2月の情報のウォン
Possible Solutions:
可能なソリューション:
Where IMAP channel is appropriate, the external channel may be binary capable; that is, the external access may not require re-encoding. Mechanisms such as HTTP [24], FTP, or RTSP are available for this download.
IMAPチャンネルが適切であるところでは、外部のチャンネルはバイナリーできるかもしれません。 すなわち、外部のアクセスは、再コード化するのを必要としないかもしれません。 HTTP[24]、FTP、またはRTSPなどのメカニズムはこのダウンロードに利用可能です。
The IMAP binary extension standards proposal [31] extends the IMAP fetch command to retrieve data in the binary form. This is especially useful for large attachments and other binary components. Binary in conjunction with a streaming client implementation may be an attractive alternative to the channel extension.
IMAPの2進の拡大規格提案[31]は二部形式でデータを検索するIMAPとって来コマンドを広げています。 これは特に大きい付属と他の2進のコンポーネントの役に立ちます。 ストリーミングのクライアント実装に関連したバイナリーはチャンネル拡大への魅力的な代替手段であるかもしれません。
6.1.2. Functional Issues
6.1.2. 機能的な問題
6.1.2.1. Mailbox Summary Support
6.1.2.1. メールボックス概要サポート
The common TUI prompt, "you have two new voice messages, six unheard messages, and one new fax message", requires more information than is conveniently made available by current message retrieval protocols.
「あなたには、2つの新しい音声メール、6つの聞こえないメッセージ、および1つの新しいファックス通信がある」という一般的なTUIプロンプトは現在のメッセージ検索プロトコルによって便利に利用可能に作られるより多くの情報を必要とします。
The existing IMAP protocol's mailbox status command does not include a count by message context [26] [27]. A possible solution is for the mail server to keep track of these current counters and provide a status command that returns an arbitrary mailbox summary. The IMAP status command provides a count of new and total messages with standardized attributes extracted from the message headers. This predetermined information does not currently include information about the message type. Without additional conventions to the status command, a client would have to download the header for each message to determine its type, a prohibitive cost where latency or bandwidth constraints exist.
既存のIMAPプロトコルのメールボックス状態コマンドはメッセージの文脈[26][27]でカウントを含んでいません。 可能なソリューションは、メールサーバがこれらの現在のカウンタの動向をおさえて、任意のメールボックス概要を返す状態コマンドを提供することです。 IMAP状態コマンドはメッセージヘッダーから抽出される標準化された属性に新しくて総メッセージのカウントを提供します。 この予定された情報は現在、メッセージタイプの情報を含んでいません。 状態コマンドへの追加コンベンションがなければ、クライアントはタイプを決定する各メッセージのためにヘッダーをダウンロードしなければならないでしょう、潜在か帯域幅規制が存在するひどく高い費用。
6.1.2.2. Sort by Message Context Support
6.1.2.2. メッセージの文脈で、サポートを分類してください。
This functionality is required to present new voice messages first and then new fax messages within a single logical queue as voice mailboxes commonly do. Again, this is a question of convenience and performance. Adequate performance may only be possible if the mail server provides a sort by context or maintains a set of virtual mailboxes (folders) corresponding to message types as for "Mailbox Summary Support", Section 6.1.2.1.
この機能性が、ボイス・メールボックスとしてのただ一つの論理的な待ち行列の中の1番目の、そして、次に、新しいファックス通信が一般的にする新しい音声メールを提示するのに必要です。 一方、これは便利と性能の問題です。 メールサーバが文脈で種類を提供するか、または.1に、「メールボックス概要サポート」、セクション6.1.2のようにメッセージタイプにおいて対応しているのに1セットの仮想のメールボックス(フォルダー)を維持する場合にだけ、適切な性能は可能であるかもしれません。
IMAP does not support this directly. A straightforward solution is to define an extensible sort mechanism for sorting on arbitrary header contents.
IMAPは直接これをサポートしません。 簡単なソリューションはソーティングのために任意のヘッダーコンテンツで広げることができる種類のメカニズムを定義することです。
Wong Informational [Page 16] RFC 4416 LEMONADE Goals February 2006
[16ページ]RFC4416レモネード目標2006年2月の情報のウォン
6.1.2.3. Status of Multiple Mailboxes Support
6.1.2.3. 複数のメールボックスサポートの状態
Extension mailbox support requires the ability to efficiently status a mailbox other than the one currently logged into. This facility is required to support sub-mailboxes, where a common feature is to check whether other sub-mailboxes in the same family group have new messages.
拡大メールボックスサポートが能力を必要とする、効率的に、もの以外の状態aメールボックスは現在、ログインされました。 この施設はサブメールボックスを支えなければなりません。そこでは、共通点は同じ家族集団における他のサブメールボックスには新しいメッセージがあるかどうかチェックすることです。
Current mechanisms are limited to logging into each of set of mailboxes, checking status, logging out, and repeating until all sub-mailboxes are processed.
現在のメカニズムはそれぞれのメールボックスのセットにログインするのに制限されます、すべてのサブメールボックスが処理されるまで、状態をチェックして、ログアウトして、繰り返して。
6.1.2.4. Specialized Mailbox Support
6.1.2.4. 専門化しているメールボックスサポート
Applications that provide features such as check receipt, deleted message recovery, resave, and others, require the ability to access messages in predetermined mailboxes with specific behaviors (e.g., Outbox, Sent Items, Deleted Items, Expired Items, Drafts).
チェック領収書などの特徴を提供するアプリケーション(削除されたメッセージ回復、「再-セーブ」、および他のもの)が、特異的行動(例えば、送信トレイ、Sent Items、Deleted Items、Expired Items、Drafts)で予定されたメールボックスの中のメッセージにアクセスする能力を必要とします。
IMAP provides only a single standardized folder, the inbox. This functionality does not require new protocol additions per se, but standardized usage and naming conventions are necessary for interoperability. This functionality requires that the server provide the underlying logic to support these special folders, including automatic insertion, scheduled copying, and periodic deletion.
IMAPは単一の標準化されたフォルダー、受信トレイだけを提供します。 この機能性はそういうものとして新しいプロトコル追加を必要としませんが、標準化された用法と命名規則が相互運用性に必要です。 この機能性は、サーバがこれらが特別なフォルダーであるとサポートするために基本的な論理を提供するのを必要とします、自動挿入、予定されているコピー、および周期的な削除を含んでいて。
6.1.2.5. CLID Restriction Indication/Preservation
6.1.2.5. CLID制限指示/保存
Many calling features are dependent on collected caller-ID information. Clients -- such as the TUI and other service supporting user agents (e.g., WEB and WAP servers) -- may need trusted access to restricted caller-ID information for such purposes as callback. Untrusted clients must not be permitted to receive this information. A mechanism for establishing "trust" between appropriate clients and the server is required to restrict delivery of this information to the end-user only as allowed.
多くの呼ぶことの特徴が集まっている発信者番号情報に依存しています。 ユーザエージェント(例えば、WEBとWAPサーバ)をサポートするTUIや他のサービスなどのクライアントはコールバックのような目的のための制限された発信者番号情報への信じられたアクセスを必要とするかもしれません。 信頼されていないクライアントがこの情報を受け取ることが許可されてはいけません。 適切なクライアントとサーバの間の「信頼」を設立するためのメカニズムが、単に許容されているようにこの情報の配送をエンドユーザに制限するのに必要です。
Further, when messages are sent between servers within a network, a means of communicating trust is needed so that the identity of the sender can be preserved for record-keeping and certain features while ensuring that the identity is not disclosed to the recipient in an inappropriate way.
ネットワークの中でサーバの間にメッセージを送るとき、さらに、アイデンティティが不適当な方法で受取人に明らかにされないのを確実にしている間、記録保存とある特徴のために送付者のアイデンティティを保持できるように信頼を伝える手段を必要とします。
Wong Informational [Page 17] RFC 4416 LEMONADE Goals February 2006
[17ページ]RFC4416レモネード目標2006年2月の情報のウォン
6.1.2.6. Support for Multiple Access to Mailbox
6.1.2.6. メールボックスへの複数のアクセスのサポート
If the telephone answering application client uses IMAP4 for greeting access and message deposit, it is essential that the server provide support for simultaneous login. It is common in voice mail for an incoming call to be serviced by the telephone answering application client at the same time the subscriber is logged into her mailbox. Further, new applications such as WEB and WAP access to voice mail may entail simultaneous login sessions, one from the TUI client and one from the visual client.
アプリケーションクライアントに答える電話が挨拶アクセスとメッセージ預金にIMAP4を使用するなら、サーバが同時のログインのサポートを提供するのは、不可欠です。 電話によって修理されるというかかってきた電話に、それは、加入者が彼女のメールボックスに登録される同時代にアプリケーションクライアントに答えながら、ボイスメールで一般的です。 さらに、WEBやWAPアクセスなどのボイスメールへの新しい応用は同時のログインセッション、TUIクライアントからの1、および視覚クライアントからの1つを伴うかもしれません。
The existing standard does not preclude multiple accesses to a mailbox, but it does not explicitly require support of the practice. The lack of explicit support requires the server and client to adhere to a common set of practices and behaviors to avoid undesirable and unpredictable behaviors. RFC2180 [29] describes a candidate set of conventions necessary to support this multiple-access technique. It or some other method MUST be standardized as part of LEMONADE.
既存の規格はメールボックスへの複数のアクセスを排除しませんが、それは明らかに習慣のサポートを必要としません。 明白なサポートの不足は、サーバとクライアントが望ましくなくて予測できない振舞いを避けるために習慣と一般的な振舞いを固く守るのを必要とします。 RFC2180[29]はこの複数のアクセスがテクニックであるとサポートするのに必要なコンベンションの候補セットについて説明します。 LEMONADEの一部としてそれかある他のメソッドを標準化しなければなりません。
6.2. Requirements on the Message Submission Protocol [22]
6.2. メッセージ服従プロトコルに関する要件[22]
6.2.1. Forward without Download Support
6.2.1. ダウンロードなしでサポートを進めてください。
It is common to forward messages or to reply to messages with a copy of their attached content. Today such forwarding requires the sender to download a complete copy of the original message, attach it to the reply or forward message, and resubmit the result. For large messages, this represents a substantial amount of bandwidth and processing. For clients connected via long-thin pipes, alternatives are required.
メッセージを転送するか、またはそれらの添付の内容のコピーでメッセージに答えるのが一般的です。 今日、そのような推進は、送付者がオリジナルのメッセージの完本をダウンロードして、回答か前進のメッセージにそれを付けて、結果を再提出するのを必要とします。 大きいメッセージに関しては、これはかなりの量の帯域幅と処理を表します。 長い薄いパイプを通して接されたクライアントに関しては、代替手段が必要です。
One approach is to define an extension to message submission to request the submission server to resolve embedded URLs within a message before relaying the message to the final destination. This approach is referred to as the pull approach because the message submission server must pull data from the IMAP server.
1つのアプローチは最終的な目的地にメッセージをリレーする前にメッセージの中で埋め込まれたURLを決議するよう服従サーバに要求するためにメッセージ提案と拡大を定義することです。 メッセージ服従サーバがIMAPサーバからデータを引かなければならないので、このアプローチは牽引力のアプローチと呼ばれます。
Another approach is to add a limited message assembly and submission capability to the IMAP server. This approach muddies the distinction between the message submission protocol and that for message storage and retrieval (IMAP) because now message submission may be a side effect of message store commands. This approach is referred to as the push approach because in this case the IMAP server pushes data to the message submission server.
別のアプローチはIMAPサーバへの限られたメッセージアセンブリと服従能力を加えることです。現在メッセージ提案がメッセージ保存命令の副作用であるかもしれないので、このアプローチはメッセージストレージと検索(IMAP)のためにメッセージ服従プロトコルとそれでの区別を濁します。 IMAPサーバがこの場合メッセージ服従サーバにデータを押すので、このアプローチはプッシュアプローチと呼ばれます。
A detailed analysis of which of the two approaches is preferable as well as implementation details of both can be found in references [36], [37], [38], [39], [40], and [41].
2つのもののどれにアプローチするかに関する詳細に渡る分析は参照[36]、[37]、[38]、[39]、[40]、および[41]で両方の実装の詳細を見つけることができるのと同じくらい十分望ましいです。
Wong Informational [Page 18] RFC 4416 LEMONADE Goals February 2006
[18ページ]RFC4416レモネード目標2006年2月の情報のウォン
6.2.2. Quota by Context Enforcement
6.2.2. 文脈実施による割当て
It is common in a unified messaging system to offer separate quotas [11] for each of several message contexts to avoid the condition where a flood of email fills the mailbox and prevents the subscriber from receiving voice messages via the telephone. It is necessary to extend the protocols to support the reporting of the "mailbox full" status based on the context of the submitted message.
ユニファイド・メッセージングシステムでは、それぞれに関するいくつかのメッセージの文脈が加入者がメールの洪水のためにメールボックスをいっぱいにしていて、電話を通して音声メールを受け取ることができない状態を避けるように別々の割当て[11]を提供するのは一般的です。 提出されたメッセージの文脈に基づく「メールボックス満」状態の報告をサポートするためにプロトコルを広げるのが必要です。
An obvious security issue needing consideration is the prevention of the deliberate misidentification of a message context with the intention of overflowing a subscriber's mailbox. It is envisioned that the message submission protocol will require the authentication of trusted submission agents allowing only those so authorized to submit distinguished messages.
加入者のメールボックスからはみ出すという意志で考慮を必要とする明白な安全保障問題はメッセージの文脈の慎重な誤認の防止です。 それは思い描かれます。メッセージ服従プロトコルが提出するのがそのように認可されたものだけを許す信じられた服従エージェントを認証に要求するのがメッセージを区別しました。
Voice mail system mailboxes commonly contain voice and fax messages. Sometimes, such systems also support email messages (text, text with attachments, and multimedia messages) in addition to voice messages. Similar to the required sort by message context, quota management is also required per message context.
ボイスメールシステムメールボックスは一般的に声とファックス通信を含んでいます。 また、時々、そのようなシステムは、メールが音声メールに加えたメッセージ(テキスト、付属のテキスト、およびマルチメディアメッセージ)であるとサポートします。 メッセージの文脈で必要な種類と同様であることで、また、割当て管理がメッセージの文脈単位で必要です。
One possible use case is the prevention of multiple (large) messages of one type (e.g., email messages) from consuming all available quota. Consumption of all quota by one type prevents the delivery of other types (e.g., voice or fax messages) to the mailbox.
可能な使用がケースに入れる1つはすべての有効な割当てを消費するのからの1つのタイプ(例えば、メールメッセージ)の複数の(大きい)のメッセージの防止です。 1つのタイプによるすべての割当ての消費は他のタイプ(例えば、声かファックス通信)の配送をメールボックスに防ぎます。
One possible approach is to define a mechanism whereby a trusted client can declare the context of a message for the purpose of utilizing a protected quota. This may be by extensions to the SMTP-submit or LMTP[35] protocols.
1つの可能なアプローチは信じられたクライアントが保護された割当てを利用する目的へのメッセージの文脈を宣言できるメカニズムを定義することです。 これはSMTP提出しているか、LMTP[35]プロトコルへの拡大であるかもしれません。
6.2.3. Future Delivery Support with Cancel
6.2.3. キャンセルとの今後の配送サポート
Traditionally messages sent with "future delivery" are held in the recipient's client "outbox" or its equivalent until the appointed submission time. Thin clients used with TUIs do not have such persistent storage or may be intermittently connected and must rely upon server-based outbox queues.
伝統的に、「今後の配送」と共に送られたメッセージは受取人のクライアント「送信トレイ」かその同等物で指定している服従時間まで保持されます。 TUIsと共に使用されるシンクライアントは、そのような永続的なストレージを持ってはいけませんし、断続的に関連づけられるかもしれなくて、またサーバベースの送信トレイ待ち行列を当てにされなければなりません。
Such support requires extensions to message submission protocols to identify a message as requiring queuing for future delivery. Extensions to IMAP4 or SMTP are required for viewing and manipulating the outbound queue, for such purposes as canceling a future message. Server support for managing such a queue is required so that messages are sent when they are intended.
そのようなサポートは、今後の配送のために列を作るのが必要であるとしてメッセージを特定するためにメッセージ服従プロトコルに拡大を必要とします。 IMAP4かSMTPへの拡大が外国行きの待ち行列を見て、操るのに必要です、将来のメッセージを取り消すような目的のために。 そのような待ち行列を管理するサーバサポートが必要であるので、それらを意図するとき、メッセージを送ります。
Wong Informational [Page 19] RFC 4416 LEMONADE Goals February 2006
[19ページ]RFC4416レモネード目標2006年2月の情報のウォン
Some of the architectural issues here are the same as those in "Forward without Download Support" (Section 6.2.1).
ここの構造的な問題のいくつかが「ダウンロードサポートのないフォワード」(セクション6.2.1)のそれらと同じです。
6.2.4. Support for Committed Message Delivery
6.2.4. 遂行されたメッセージ配送のサポート
Voice messaging service has provided a high degree of reliability and performance for telephone answering messages. The expectation is that once the caller has hung up, the message is in the mailbox and available for review. The traditional Internet mail architecture suggests these messages should be sent to the mailbox via SMTP. This approach has two limitations. The first and most manageable is that the message forwarding may take more time than is tolerable by the subscriber. The second is that the message may fail to be delivered to the mailbox. Because there is no way to return notice to the caller, the message is "lost".
声のメッセージングサービスは高度合いの信頼性と性能をメッセージに答える電話に供給しました。 期待は訪問者がいったんハングアップすると、メッセージがメールボックスの中にあって、レビューに利用可能であるということです。 伝統的なインターネット・メールアーキテクチャは、これらのメッセージがSMTPを通してメールボックスに送られるべきであると示唆します。 このアプローチには、2つの制限があります。 1番目で最も処理しやすいのは、メッセージ推進が加入者が許容できるより多くの時間がかかるかもしれないということです。 2番目はメッセージによってメールボックスに提供されないかもしれないということです。 通知を訪問者に返す方法が全くないので、メッセージは「無くなっています」。
The standards community is working on an alternative to SMTP called Local Message Transport Protocol (LMTP[35]). This protocol addresses a number of limitations in SMTP when used to provide atomic delivery to a mailbox. The failure modes in this proposal are carefully controlled, as are issues of per-message quota enforcement and message storage quota-override for designated administrative messages.
規格共同体はLocal Message Transportプロトコルと呼ばれるSMTPへの代替手段に取り組んでいます。(LMTP[35])。 原子配送をメールボックスに供給するのに使用されると、このプロトコルはSMTPでの多くの制限を扱います。 この提案における故障モードは指定された管理メッセージのために1メッセージあたりの割当て実施とメッセージストレージ割当てオーバーライドの問題のように慎重に制御されます。
An alternative approach is to misuse the IMAP protocol and use an IMAP-based submission mechanism to deposit a message directly into the recipient's inbox. This append must be done by a special super-user with write permissions into the recipient mailbox. Further, the message store must be able to trigger notification events upon insertion of a message into the mailbox via the Append command. The historic limitation on using IMAP4 for message sending involves the inability of IMAP to communicate a full SMTP envelope. For telephone answering, these limitations are not significant. However, the architectural issues raised by this approach are significant. See "Forward without Download Support" (Section 6.2.1).
代替的アプローチは、受取人の受信トレイの直接中にメッセージを預けるのにIMAPプロトコルを誤用して、IMAPベースの服従メカニズムを使用することです。 これが追加する、特別なスーパーユーザにしなければならない、受取人メールボックスの中に許容を書いてください。 さらに、メッセージ店はメッセージの挿入のときにAppendコマンドでメールボックスの中に通知イベントの引き金となることができなければなりません。 メッセージ送信にIMAP4を使用するときの歴史的な制限はIMAPがいっぱいのSMTP封筒を伝えることができないことにかかわります。 電話回答において、これらの制限は重要ではありません。 しかしながら、このアプローチで提起された構造的な問題は重要です。 「ダウンロードなしでサポートを進めてください。」(セクション6.2.1)と確実にしてください。
6.3. Requirements on Message Notification
6.3. メッセージ通知に関する要件
Clients keep local information about the IMAP store. This information must be kept synchronized with the state of the store.
クライアントはIMAP店のローカルの情報を保ちます。 店の状態に連動するようにこの情報を保たなければなりません。
For example, voice mail systems traditionally notify subscribers of certain events happening in their mailbox. It is common to send an SMS or a pager notification for each message arrival event, message read event, mailbox full event, etc.
例えば、あるイベントがそれらのメールボックスの中に起こるのについてボイスメールシステムは加入者に伝統的に通知します。 それぞれのメッセージ到着イベント、イベントが読まれたメッセージ、メールボックスの完全なイベントなどのためのSMSかポケットベル通知を送るのは一般的です。
Wong Informational [Page 20] RFC 4416 LEMONADE Goals February 2006
[20ページ]RFC4416レモネード目標2006年2月の情報のウォン
When implemented over IMAP-based message stores, the voice mail client needs to be notified about these events. Furthermore, when other applications access/manipulate the store, these events need to be communicated to the mail client. In some cases, the client needs to notify the user immediately. In most cases, it is a question of maintaining client/application consistency. In the case of a multimodal client, it is especially important to provide a means of coordinating the client's different modal views of the state of the store.
IMAPベースのメッセージ店の上で実装されると、ボイスメールクライアントは、これらのイベントに関して通知される必要があります。 他のアプリケーションが店をアクセスするか、または操るとき、その上、これらのイベントは、メールクライアントとコミュニケートする必要があります。 いくつかの場合、クライアントは、すぐにユーザに通知する必要があります。 多くの場合、それはクライアント/アプリケーションが一貫性であることを支持する問題です。 マルチモーダルクライアントの場合では、クライアントの店の状態の異なった様式の視点を調整する手段を提供するのは特に重要です。
Email systems have traditionally polled to update this information. There may be advantages to an event-driven approach in some cases.
メールシステムに、この情報をアップデートするために伝統的に投票しました。 いくつかの場合、イベントドリブンアプローチの利点があるかもしれません。
The standards community is working on a standard for bulk server-to-client status notification. An example of such work is the Simple Notification and Alarm Protocol (SNAP) [45], which defines the expected behavior of the message store for various events, many of them triggered by IMAP commands.
規格共同体はサーバからクライアントへの状態大量の通知の規格に取り組んでいます。 そのような仕事に関する例はSimple Notificationです、そして、Alarmプロトコル(SNAP)[45](様々なイベントのためにメッセージ店の予想された動きを定義する)はIMAPで命令します。それらの多くがイベントのために引き起こされます。
6.3.1. Additional Requirements on Message Notification
6.3.1. メッセージ通知に関する追加要件
A format for message notification for servers reporting status information to other servers (e.g., IMAP4 server to SMS or pager server) MUST be defined. The method for delivery of these notifications MUST also be specified.
他のサーバ(例えば、SMSへのIMAP4サーバかポケットベルサーバ)に状態情報を報告するサーバのためのメッセージ通知のための書式を定義しなければなりません。 また、これらの通知の配送のためのメソッドを指定しなければなりません。
The design for this MUST take into account the IAB note: "Unified Notification Protocol Considerations" (Appendix C).
これのためのデザインはIAB注意を考慮に入れなければなりません: 「統一された通知プロトコル問題。」(付録C)
7. Issues and Requirements: WUI Mobility Aspects
7. 問題と要件: WUI移動性局面
7.1. Wireless Considerations on Email
7.1. メールに関するワイヤレスの問題
7.1.1. Transport Considerations
7.1.1. 輸送問題
Compared to a LAN/WAN configuration or even to a wire-line dial-up connection, the probability of an interruption to a wireless connection is very high.
LAN/WAN構成、または、ワイヤー・ラインダイアルアップ接続とさえ比べて、無線接続への中断の確率は非常に高いです。
Interruptions can be due to handoff, signal fading, or stepping beyond cell coverage.
中断は移管、信号の色あせ、またはセル適用範囲を超えて踏むためであることができます。
In addition, because the mobile handset is also used for other types of communications, there is a relatively high probability that the data session will be interrupted either by incoming voice calls or by "pushed" messages from services such as SMS, MMS, and WAP.
さらに、また、移動体端末が他のタイプに関するコミュニケーションに使用されるので、データセッションが入って来る音声通話か「押された」メッセージによって中断されるという比較的高い確率はSMSや、MMSや、WAPなどのサービスから来ています。
Wong Informational [Page 21] RFC 4416 LEMONADE Goals February 2006
[21ページ]RFC4416レモネード目標2006年2月の情報のウォン
It is also common in these environments that the device's IP address change within a session.
また、それもデバイスのIPアドレスがセッション以内に変えるこれらの環境で一般的です。
7.1.2. Handset-Resident Client Limitations
7.1.2. 受話器居住者クライアント制限
Although the capabilities of wireless handsets are rapidly improving, the wireless handset remains limited in its capability to host email clients. Currently, email access is restricted to only high-end wireless handsets.
ワイヤレスの受話器の能力は急速に向上していますが、ワイヤレスの受話器は能力がホストメールクライアントに制限されたままで残っています。 現在、メールアクセスはハイエンドワイヤレス受話器だけに制限されます。
These limitations include:
これらの制限は:
o Client size
Handset-resident clients are limited in size because either the
handset has limited storage space or the handset vendor/network
operator has set a limit on the size of client application that
can reside on the handset.
o Runtime memory
Wireless handsets have limited runtime memory for the use of
the mobile email client.
o CPU Speed
Wireless handsets have CPUs that are inferior to those in
conventional systems (PCs) that run email clients.
o User Interface
Handsets have very limited input and output capabilities. Most
of them have only a rudimentary keyboard (a keypad) and a
rudimentary pointing device (a text cursor).
o 受話器が集積スペースを制限したか、または受話器ベンダー/ネットワーク・オペレータが受話器の上にあることができるクライアントアプリケーションのサイズにおける限界を設定したので、クライアントサイズHandset-居住者クライアントはサイズが制限されます; o RuntimeメモリWireless受話器はモバイルメールクライアントの使用のためのランタイムメモリを制限しました。o CPU Speed Wireless受話器はメールクライアントを車で送る従来のシステム(PC)にそれらより粗悪なCPUを持っています。o User Interface Handsetsには、非常に限られた入力と出力能力があります。 彼らの大部分には、初歩的なキーボード(キーパッド)と初歩的なポインティング・デバイス(テキストカーソル)しかありません。
7.1.3. Wireless Bandwidth and Network Utilization Considerations
7.1.3. ワイヤレスの帯域幅とネットワーク利用問題
7.1.3.1. Low Bandwidth
7.1.3.1. 低い帯域幅
2G mobile networks enabled wireless data communications, but only at very low bandwidths using circuit-switched data. 2.5G and 3G networks improve on this. However, existing email clients require very large files (up to several MBs) -- encountered in multi-media attachments such as presentations, images, voice, and video -- to be downloaded even though mobiles cannot exploit most of the data (because of color depth and screen size limitations). Transferring such large files over the air is of questionable value even when higher wireless bandwidth is available.
ワイヤレスのデータ通信を可能にしましたが、2Gモバイルネットワークは回路で切り換えられたデータを使用する非常に低い帯域幅だけでそうしました。 2.5 Gと3Gネットワークはこれを改良します。 しかしながら、モバイルはデータ(色の濃さと画面サイズ制限による)の大部分を利用できませんが、既存のメールクライアントは、非常に大きいファイル(数個のMBまでの)(プレゼンテーションや、イメージや、声や、ビデオなどのマルチメディア付属では、遭遇する)がダウンロードされるのを必要とします。 より高いワイヤレスの帯域幅が利用可能であるときにさえ、そのような大きいファイルを空気の上に移すのにおいて、疑わしい価値があります。
7.1.3.2. Price Sensitivity
7.1.3.2. 価格感度
In many cases, users of mobile data services are charged by the amount of data (e.g., kilobytes) downloaded to the handset. Most users currently experience a higher per-kilobyte data charge with a wireless service than they do over a wire-line service. Users are
多くの場合、モバイルデータサービスのユーザは受話器にダウンロードされたデータ(例えば、キロバイト)の量によって請求されます。 ほとんどのユーザが現在、無線電信便の1キロバイトあたり1つのワイヤー・ラインサービスの上で経験するより高いデータ充電を経験します。 ユーザはそうです。
Wong Informational [Page 22] RFC 4416 LEMONADE Goals February 2006
[22ページ]RFC4416レモネード目標2006年2月の情報のウォン
sensitive to the premium for wireless service. This results in an unwillingness to download large amounts of unnecessary data to the handset and the desire to be able to download only selected content.
プレミアムに、無線電信便において、敏感です。 これは多量の不要なデータを受話器にダウンロードするために気がすすまないことに結果として生じました、そして、ダウンロードできる願望は内容を選択しただけです。
7.1.3.3. File Size Limitations
7.1.3.3. ファイルサイズ制限
In some cases, the size of file that can be transmitted over the air to the handset is limited. This is a consequence of handset limitations (Section 7.1.2), wireless media and bandwidth issues (Section 7.1.1 and Section 7.1.3.1), and price sensitivity (Section 7.1.3.2).
いくつかの場合、受話器への空気の上に送ることができるファイルのサイズは限られています。 これが受話器制限(セクション7.1.2)、ワイヤレスのメディア、および帯域幅問題の結果である、(セクション7.1.1とセクション7.1.3の.1、)および価格感度、(セクション7.1 .3 .2)。
7.1.4. Content Display Considerations
7.1.4. 満足しているディスプレイ問題
7.1.4.1. Display Size and Capabilities
7.1.4.1. ディスプレイサイズと能力
Wireless terminals are currently limited in their display size, color depth, and ability to present multimedia elements (i.e., if multiple pictures are sent, the mobile can usually present only one reduced- sized picture element at a time rather than the several picture elements at once in the same display that a conventional PC email client would be able to show). Therefore, many email attachments destined for a mobile may require changes in size, color depth, and presentation method in order to be suitably displayed.
ワイヤレスの端末は現在、それらのディスプレイサイズ、色の濃さ、およびマルチメディア要素を提示する能力が制限されます(すなわち、複数の画像を送るなら、通常、モバイルはすぐに同じディスプレイにおける数個の画像要素よりむしろ従来のPCメールクライアントが目立つことができるだろう時に1つの減少している大きさで分けられた画素しか提示できません)。 したがって、モバイルのために運命づけられた多くのメール付属が、適当に表示するためにサイズ、色の濃さ、およびプレゼンテーションメソッドで釣り銭がいるかもしれません。
7.1.4.2. Supported Media Formats
7.1.4.2. サポートしているメディア形式
Wireless handsets can only display a limited set of media format types. Although PC clients support a large variety of document types (and allow on-demand "codec"/player download), mobiles have very limited support. (For example, most only support WAV audio and cannot play other formats such as AU, MP3 and AIFF.) Furthermore, although almost all new handsets sold today can display images and sound in some advanced format, support for displaying other media or application-specific formats, such as MS Office (TM), is not expected to be widespread in the near future.
ワイヤレスの受話器は形式がタイプするメディアの限られたセットを表示できるだけです。 PCクライアントはさまざまなドキュメントタイプをサポートしますが(要求次第の「コーデック」/プレーヤーダウンロードを許容してください)、モバイルには、非常に限られたサポートがあります。 (例えば、大部分は、音声データのファイル・フォーマットがオーディオであるとサポートするだけであり、AUや、MP3やAIFFなどの他の形式をプレーできません。) その上、今日販売されているほとんどすべての新しい受話器が、何らかの高度な形式でイメージを表示して、鳴ることができますが、他のメディアを表示するサポートかMSオフィス(TM)などのアプリケーション特有の形式が近い将来広範囲でないと予想されます。
7.1.4.3. Handset Type Variety
7.1.4.3. 受話器タイプのバラエティー
As mentioned above, there are many handset types available in the market, and each has different display capabilities, screen characteristics, and processing capabilities. The mobile email service should be able to support as many handset types as possible.
以上のように、市場に手があいている多くの受話器タイプがあります、そして、それぞれには、異なったディスプレイ能力、スクリーンの特性、および処理能力があります。 モバイルメールサービスはできるだけ多くの受話器タイプをサポートすることができるべきです。
Wong Informational [Page 23] RFC 4416 LEMONADE Goals February 2006
[23ページ]RFC4416レモネード目標2006年2月の情報のウォン
7.1.4.4. Specific Attachment Display Scenarios
7.1.4.4. 特定の付属ディスプレイシナリオ
Handsets are unsuitable for perusing entire lengthy documents or presentations. Rather than go through the whole document, a mobile user is more likely to look at several pages of a document or several slides of a presentation and then take action accordingly (e.g., forward the email message to another recipient, print it, or leave the document for later retrieval from another device).
全体の長いドキュメントかプレゼンテーションを熟読するのに、受話器は不適当です。 むしろ、モバイルユーザは、ドキュメントの数ページかプレゼンテーションの数個のスライドを見て、次に、全体のドキュメントを通って行くよりそれに従って、行動を取りそうです(例えば、メールメッセージを別の受取人に転送してください、それを印刷してください、または別のデバイスから後の検索のためのドキュメントを外してください)。
Therefore, there is a need to enable users to download not the entire attachment but rather just a selected part of it. For example, users should be able to download the "Table of Contents" of a document; to search within a document; to download the first slide of a presentation; the next slide of this presentation or a range of slides, etc.
したがって、ユーザが全体の付属ではなく、むしろまさしくそれの選択された部分をダウンロードするのを可能にする必要があります。 例えば、ユーザはドキュメントの「目次」をダウンロードできるべきです。 ドキュメントの中に捜すために。 プレゼンテーションの最初のスライドをダウンロードするために。 このプレゼンテーションかさまざまなスライドの次のスライドなど
7.2. Requirements to Enable Wireless Device Support
7.2. ワイヤレス機器サポートを可能にするという要件
The following requirements are derived from the considerations mentioned above.
前記のように問題から以下の要件を得ます。
7.2.1. Transport Requirements
7.2.1. 輸送要件
The mobile email protocol must anticipate transient losses of connectivity and allow clients to recover (restore state) from interrupted connections quickly and easily.
モバイルメールプロトコルは、接続性の一時的な損失を予期して、クライアントが中断している接続からすぐに、容易に回復するのを(状態を回復します)許容しなければなりません。
IMAP4 Context
IMAP4文脈
An IMAP4 connection requires the communication socket to remain up continuously during an email session. In case of transient loss of communications, the connection must be reestablished. It is up to the client to reconnect to the server and return to an equivalent state in the session. This overhead of restoring connections is very costly in response time and additional data transmission.
IMAP4接続はメールセッションの間に絶え間なく上がり続けるコミュニケーションソケットを必要とします。 コミュニケーションの一時的な損失の場合には、接続は回復しなければなりません。 サーバに再接続して、セッションのときに同等な状態に戻るのは、クライアント次第です。 接続を復元するこのオーバーヘッドは応答時間と追加データ伝送で非常に高価です。
7.2.2. Enhanced Mobile Email Functionality
7.2.2. 高められたモバイルメールの機能性
7.2.2.1. Forward without Fetch
7.2.2.1. フェッチなしで前進しています。
To minimize the downloading of data over the air, the user MUST be able to forward a message without initially downloading it entirely or at all to the handset.
空気の上でデータのダウンロードを最小にするために、初めは全くそれを受話器に完全にダウンロードしないで、ユーザはメッセージを転送できなければなりません。
The mobile email protocol MUST support the ability to forward a message without retrieving it.
モバイルメールプロトコルはそれを検索しないでメッセージを転送する能力をサポートしなければなりません。
Wong Informational [Page 24] RFC 4416 LEMONADE Goals February 2006
[24ページ]RFC4416レモネード目標2006年2月の情報のウォン
This requirement is identical to the TUI requirement described in "Forward Without Download Support" (Section 6.2.1).
この要件は「ダウンロードサポートのないフォワード」(セクション6.2.1)で説明されたTUI要件と同じです。
7.2.2.2. Media Streaming
7.2.2.2. メディアストリーミング
The mobile email protocol MUST provide a solution that will enable media streaming to the wireless handset.
モバイルメールプロトコルはワイヤレスの受話器へのストリーミングのメディアを可能にする解決法を提供しなければなりません。
This requirement is similar to the TUI requirement described in "Real-Time Playback" (Section 6.1.1.1).
この要件が「リアルタイムの再生」で説明されたTUI要件と同様である、(セクション6.1 .1 .1)。
7.2.3. Client Requirements
7.2.3. クライアント要件
IMAP4 clients are large because IMAP4 already consists of a complex set of functions (e.g., parsing of a broad variety of MIME formats).
IMAP4が複雑な関数群(例えば、広いバラエティーのMIME形式の構文解析)から既に成るので、IMAP4クライアントは大きいです。
The mobile email client should be: o Small in size o Efficient in CPU consumption o Efficient in runtime memory consumption
モバイルメールクライアントは以下の通りであるべきです。 o ランタイムメモリ消費におけるCPU消費o Efficientにおけるサイズo Efficientでは、小さいです。
To enable such extremely thin clients, in developing the mobile email protocol we should consider simplifying the IMAP functionality that handsets need to support. However, any such simplification MUST NOT limit interoperability with full IMAP servers.
そのようなものを可能にする、非常に、シンクライアント、モバイルメールプロトコルを開発する際に、私たちは受話器がサポートする必要があるIMAPの機能性を簡素化すると考えるべきです。 しかしながら、どんなそのような簡素化も完全なIMAPサーバで相互運用性を制限してはいけません。
7.2.4. Bandwidth Requirements
7.2.4. 帯域幅要件
The mobile email solution should minimize the amount of data transmitted over the air. There are several ways of pursuing this goal that can be used in conjunction.
モバイルメール解決は空気の上に伝えられたデータ量を最小にするべきです。 接続詞に使用できるこの目標を追求するいくつかの方法があります。
One way is the use of content transcoding and media adaptation by the server before message retrieval in order to optimize the message for the capabilities of the receiving handset.
1つの方法は、メッセージ検索の前のサーバで受信受話器の能力へのメッセージを最適化する満足しているコード変換とメディア適合の使用です。
Another possible optimization is to make the mobile email protocol itself simple, containing as little overhead as possible.
別の可能な最適化はできるだけほとんどオーバーヘッドを含んでいなくて、モバイルメールプロトコル自体を簡単にすることです。
A third approach is to minimize the bandwidth usage as described in "Avoid Content-Transfer-Encoding Data Inflation" (Section 6.1.1.2).
3番目のアプローチが「満足している転送コード化データインフレーションを避けてください」で説明されるように帯域幅用法を最小にすることである、(セクション6.1 .1 .2)。
7.2.5. Media Handling Requirements
7.2.5. 要件を扱うメディア
As described above, wireless devices have limited ability to handle media. Therefore, the server may be have to perform media manipulation activities to enable the terminal to display the data usefully.
上で説明されるように、ワイヤレス機器はメディアを扱う能力を制限しました。 したがって、サーバはそうです。有効にデータを表示するために端末を可能にするメディア操作活動を実行しなければなりません。
Wong Informational [Page 25] RFC 4416 LEMONADE Goals February 2006
[25ページ]RFC4416レモネード目標2006年2月の情報のウォン
7.2.5.1. Device Capabilities Negotiation
7.2.5.1. デバイス能力交渉
In order to support the different characteristics and capabilities of the various handset types available in the market correctly, the mobile email protocol must include provision for email content adaptation. For example, the choice of supported file formats, color depth, and screen size. Work on ESMTP transcoding (CONNEG[33]) may address this issue.
異なった特性と能力をサポートするには、正確に言えば、モバイルメールプロトコルが支給を含まなければならない市場に手があいている様々な受話器タイプでは、満足している適合をメールしてください。 例えば、サポートしているファイル形式の選択は深さ、および画面サイズを着色します。 ESMTPコード変換に取り組んでください。(CONNEG[33])はこの問題を扱ってもよいです。
7.2.5.2. Adjusting Message Attachments for Handset Abilities
7.2.5.2. 受話器能力に関する調整しているメッセージ付属
To support wireless handsets, the server could transcode the message attachments into a representation that is more suitable for that device. This behavior should be based on the device capabilities negotiation as described in "Device Capabilities Negotiation" (Section 7.2.5.1). For example, a device that cannot display GIF format, and can only display WBMP, should get a WBMP image. Devices that cannot display a PDF file should get a text version of the file.
ワイヤレスの受話器をサポートするために、サーバはそのデバイスにより適当な表現にメッセージ付属を移コード化するかもしれません。 この振舞いが「デバイス能力交渉」で説明されるようにデバイス能力交渉に基づくべきである、(セクション7.2 .5 .1)。 例えば、GIF書式を表示できないで、WBMPを表示できるだけであるデバイスは、WBMPイメージを得るはずです。 PDFファイルを表示できないデバイスはファイルのテキストバージョンを得るはずです。
The handset should control what transcoding, if any, is desired. It
should be able to retrieve the original attachment without any
changes. In addition, the device should be able to choose between
"flavors" of the transcoding. ("Present the content as thumbnail
image" is an example of such a specific media manipulation.)
受話器は、もしあればどんなコード変換が望まれているかを制御するはずです。 それは少しも変化なしでオリジナルの付属を検索できるべきです。 さらに、デバイスはコード変換の「風味」を選ぶはずであることができます。 (「サムネイル画像として内容を提示してください、」 そのような詳細に関する例がメディア操作であるか、)
Again, work on ESMTP transcoding (CONNEG[33]) may address this issue.
もう一度、ESMTPコード変換に取り組んでください。(CONNEG[33])はこの問題を扱ってもよいです。
7.2.5.3. Handling Attachment Parts
7.2.5.3. 取り扱い付属の部品
A desirable feature (but out of scope for the current LEMONADE charter) is to enable users the choice of retrieving parts of an attachment file, not just the entire attachment. The mobile email protocol should include the ability for the retrieving client to specify selected elements of an attachment for download. Such elements can be, for example, specific pages of a document, the "table of contents" of a document, or specific slides of a presentation.
望ましい特徴(しかし現在のLEMONADE特許のための範囲から)は検索の選択が分ける全体の付属だけではなく、付属ファイルのユーザを可能にすることです。 モバイルメールプロトコルは検索しているクライアントがダウンロードに関する付属の選択された要素を指定する能力を含むべきです。 例えば、そのような要素は、特定のページのドキュメント、ドキュメントの「目次」、またはプレゼンテーションの特定のスライドであるかもしれません。
Wong Informational [Page 26] RFC 4416 LEMONADE Goals February 2006
[26ページ]RFC4416レモネード目標2006年2月の情報のウォン
8. Interoperation with Existing Mobile Messaging
8. 既存のモバイルメッセージングがあるInteroperation
LEMONADE's charter includes the specification of how enhanced Internet mail will interoperate with existing mobile messaging services (e.g., MMS) to deliver messages to mobile clients.
LEMONADEの特許は高められたインターネット・メールがモバイルクライアントにメッセージを提供するために既存のモバイルメッセージングサービス(例えば、MMS)でどう共同利用するかに関する仕様を含んでいます。
8.1. Addressing of Mobile Devices
8.1. モバイル機器のアドレシング
E.164 addressing [62] is prevalent in mobile messaging services to address recipient mobiles. Consideration should be given to supporting E.164 addressing for mobile devices in addition to RFC822 addressing.
[62]を扱うE.164はモバイルメッセージングサービスでアドレス受取人モバイルに一般的です。 モバイル機器のためにRFC822アドレシングに加えてE.164がアドレシングであるとサポートすることに対して考慮を払うべきです。
8.2. Push Model of Message Retrieval [49] [50] [51]
8.2. メッセージ検索[49][50]のモデルを押してください。[51]
MMS provides a "push" option for message retrieval. The option hides network latencies and reduces the need for user-handheld interaction. If a level of support for mobiles comparable to that of MMS is desired, this mode of operation should be considered.
MMSはメッセージ検索のための「プッシュ」オプションを提供します。 オプションは、ネットワーク潜在を隠して、ユーザハンドヘルド相互作用の必要性を減少させます。 MMSのものに匹敵するモバイルのためのサポート水準が望まれているなら、この運転モードは考えられるべきです。
8.3. Message Notification [44] [55]
8.3. メッセージ通知[44][55]
Message notification was alluded to in "Requirements on Message Notification" (Section 6.3). Internet mail has not so far standardized a server-to-client notification protocol although most existing wireless mail systems use notification to avoid needless polling. Client-to-server notification is not within the LEMONADE charter.
メッセージ通知は「メッセージ通知に関する要件」(セクション6.3)で暗示されました。 ほとんどの既存のワイヤレスのメールシステムが不必要な世論調査を避けるのに通知を使用しますが、インターネット・メールは今までのところ、サーバからクライアントへの通知プロトコルを標準化していません。 LEMONADE特許の中にクライアントからサーバへの通知がありません。
8.4. Operator Issues
8.4. オペレータ問題
8.4.1. Support for End-to-End Delivery Reports and Message-Read Reports
8.4.1. 終わりから終わりへの配送レポートとメッセージで読まれたレポートのサポート
Support for committed delivery is described in Section 6.2.4, but this is different.
遂行された配送のサポートはセクション6.2.4で説明されますが、これは異なっています。
8.4.2. Support for Selective Downloading
8.4.2. 選択しているダウンロードのサポート
If a push model of message retrieval is supported, the need for selective downloading and SPAM control is especially important.
メッセージ検索のプッシュモデルがサポートされるなら、選択しているダウンロードとスパムコントロールの必要性は特に重要です。
8.4.3. Transactions and Operator Charging Units
8.4.3. トランザクションとオペレータ充電ユニット
Mobile network providers often operate on a "pay for use" service model. This brings in requirements for clearly delineated service transactions that can be reported to billing systems, and for
モバイルネットワークプロバイダーはしばしば「使用のための賃金」サービスモデルを手術します。 そしてこれが支払いシステムに報告できる明確に図で表わされたサービス取引のための要件を持って入る。
Wong Informational [Page 27] RFC 4416 LEMONADE Goals February 2006
[27ページ]RFC4416レモネード目標2006年2月の情報のウォン
positive end-to-end acknowledgement of delivery or non-delivery of messages already mentioned in Section 8.4.1. Note that billing is specifically outside the scope of the IETF.
セクション8.4.1で既に言及した配送の積極的な終端間確認かメッセージの非配送。 特にIETFの範囲の外に支払いがあることに注意してください。
8.4.4. Network Authentication
8.4.4. ネットワーク認証
Some mobile networks require network authentication as well as application authentication.
アプリケーション認証と同様にネットワーク認証を必要とするモバイルネットワークもあります。
8.5. LEMONADE and MMS
8.5. レモネードとMMS
The 3GPP MMS Reference Architecture ([48] [54]) defines seven interfaces labelled MM1 to MM7, as below:
3GPP MMS Reference Architecture([48][54])は下としてMM1とラベルされた7つのインタフェースをMM7と定義します:
Wong Informational [Page 28] RFC 4416 LEMONADE Goals February 2006
[28ページ]RFC4416レモネード目標2006年2月の情報のウォン
3GPP MMS Reference Architecture (subset)
3GPP MMS参照アーキテクチャ(部分集合)
|---------| |------------|
wireless ||-------|| | |
device || MMS || | |<- MM2 ->
|| USER |---------------------------| |---------
|| AGENT |<- MM1 ->| | to
||-------|| | | another
|---------| | | MMS
| | relay/
|--------| | | server
e.g., | | | |
Email, |EXTERNAL| | |
Fax, or| SERVER |--------------------------| |
UMS | |<- MM3 ->| |
|--------| | |
| |
|---------| | |
|"FOREIGN"| | |
| MMS |-------------------------| |
| relay/ |<- MM4 ->| |
| server | | |
|---------| | |
| MMS |
|-------| |relay/server|
| | | |
| HLR |---------------------------| |
| |<- MM5 ->| |
|-------| | |
| |
|-------| | |
| MMS | | |
| USER |---------------------------| |
| DBs |<- MM6 ->| |
|-------| | |
| |
|-------| | |
| MMS | | |
| VAS |---------------------------| |
| APPs |<- MM7 ->| |
|-------| |------------|
|---------| |------------| ワイヤレス||-------|| | | デバイス|| MMS|| | | <、- MM2->。|| ユーザ|---------------------------| |--------- || エージェント| <、- MM1、->|、| to||-------|| | | 別|---------| | | MMS| | リレー/|--------| | | サーバ、例えば。| | | | メールしてください。|外部| | | ファックス| サーバ|--------------------------| | UMS| | <、- MM3、->|、| |--------| | | | | |---------| | | |「外国です」。| | | | MMS|-------------------------| | | リレー/| <、- MM4、->|、|、| サーバ| | | |---------| | | | MMS| |-------| |リレー/サーバ| | | | | | HLR|---------------------------| | | | <、- MM5、->|、| |-------| | | | | |-------| | | | MMS| | | | ユーザ|---------------------------| | | DBs| <、- MM6、->|、| |-------| | | | | |-------| | | | MMS| | | | 管|---------------------------| | | アプリケーション| <、- MM7、->|、| |-------| |------------|
MMS - Multimedia Messaging Service
UMS - Unified Messaging Service
HLR - Home Location Register
DB - Data Base
VAS - Value Added Service
APP - Application
MMS--マルチメディア・メッセージング・サービスUMS--ユニファイド・メッセージングサービスHLR--ホーム位置のレジスタDB--データベース管--付加価値が付いたサービス装置--アプリケーション
Wong Informational [Page 29] RFC 4416 LEMONADE Goals February 2006
[29ページ]RFC4416レモネード目標2006年2月の情報のウォン
The LEMONADE profile provides an enhanced IMAP mail retrieval protocol suitable for use at interfaces MM1 and MM3.
LEMONADEプロフィールはインタフェースのMM1とMM3での使用に適した高められたIMAPメール検索プロトコルを提供します。
In addition, if the wireless device uses a LEMONADE-enhanced IMAP user agent, the enhanced IMAP protocol can be used to access Internet mail directly, as below.
さらに、ワイヤレス機器がLEMONADEによって高められたIMAPユーザエージェントを使用するなら、高められたIMAPプロトコルは、直接インターネット・メールにアクセスするのにおいて中古であって、以下であることができます。
Wong Informational [Page 30] RFC 4416 LEMONADE Goals February 2006
[30ページ]RFC4416レモネード目標2006年2月の情報のウォン
3GPP MMS Reference Architecture (subset)
3GPP MMS参照アーキテクチャ(部分集合)
|---------| |------------|
wireless ||-------|| | |
device || IMAP || | |<- MM2 ->
|| USER || | |---------
|| AGENT || | | to
||---^---|| | | another
|----|---|| | | MMS
| LEMONADE Enhanced IMAP and | | relay/
|---V----| SMTP | | server
e.g., | | | |
Email, |EXTERNAL| | |
Fax, or| SERVER |--------------------------| |
UMS | |<- MM3 ->| |
|--------| | |
| |
|---------| | |
|"FOREIGN"| | |
| MMS |-------------------------| |
| relay/ |<- MM4 ->| |
| server | | |
|---------| | |
| MMS |
|-------| |relay/server|
| | | |
| HLR |---------------------------| |
| |<- MM5 ->| |
|-------| | |
| |
|-------| | |
| MMS | | |
| USER |---------------------------| |
| DBs |<- MM6 ->| |
|-------| | |
| |
|-------| | |
| MMS | | |
| VAS |---------------------------| |
| APPs |<- MM7 ->| |
|-------| |------------|
|---------| |------------| ワイヤレス||-------|| | | デバイス|| IMAP|| | | <、- MM2->。|| ユーザ|| | |--------- || エージェント|| | | to||---^---|| | | 別|----|---|| | | MMS| そしてレモネードがIMAPを高めた。| | リレー/|---V----| SMTP| | サーバ、例えば。| | | | メールしてください。|外部| | | ファックス| サーバ|--------------------------| | UMS| | <、- MM3、->|、| |--------| | | | | |---------| | | |「外国です」。| | | | MMS|-------------------------| | | リレー/| <、- MM4、->|、|、| サーバ| | | |---------| | | | MMS| |-------| |リレー/サーバ| | | | | | HLR|---------------------------| | | | <、- MM5、->|、| |-------| | | | | |-------| | | | MMS| | | | ユーザ|---------------------------| | | DBs| <、- MM6、->|、| |-------| | | | | |-------| | | | MMS| | | | 管|---------------------------| | | アプリケーション| <、- MM7、->|、| |-------| |------------|
MMS - Multimedia Messaging Service
UMS - Unified Messaging Service
HLR - Home Location Register
DB - Data Base
VAS - Value Added Service
APP - Application
MMS--マルチメディア・メッセージング・サービスUMS--ユニファイド・メッセージングサービスHLR--ホーム位置のレジスタDB--データベース管--付加価値が付いたサービス装置--アプリケーション
Wong Informational [Page 31] RFC 4416 LEMONADE Goals February 2006
[31ページ]RFC4416レモネード目標2006年2月の情報のウォン
9. Security Considerations
9. セキュリティ問題
Security will be a very important part of enhanced messaging. The goal, wherever possible, is to preserve the semantics of existing messaging systems and to meet the (existing) expectations of users with respect to security and reliability.
セキュリティは高められたメッセージングの非常に重要な部分になるでしょう。 目標は、どこでも、可能であるところでシステムを通信させながら存在する意味論を保存して、セキュリティと信頼性に関してユーザへの(既存)の期待に合うことです。
10. References
10. 参照
10.1. Normative References
10.1. 引用規格
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[1] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
10.2. Informative References
10.2. 有益な参照
[2] Crocker, D., "Standard for the format of ARPA Internet text
messages", STD 11, RFC 822, August 1982.
[2] クロッカー、D.、「ARPAインターネット・テキスト・メッセージの形式の規格」、STD11、RFC822、1982年8月。
[3] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service
Extension for Delivery Status Notifications (DSNs)", RFC 3461,
January 2003.
[3] ムーア、K.、「配送状態通知(DSNs)のためのシンプルメールトランスファプロトコル(SMTP)サービス拡大」、RFC3461、2003年1月。
[4] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD
53, RFC 1939, May 1996.
[4] マイアーズ、J.、およびM.ローズ、「郵便局は議定書を作ります--バージョン3インチ、STD53、RFC1939、1996年5月。」
[5] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies",
RFC 2045, November 1996.
解放された[5]、N.、およびN.Borenstein、「マルチパーパスインターネットメールエクステンション(MIME)は1つを分けます」。 「インターネットメッセージ本体の形式」、RFC2045、1996年11月。
[6] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, November
1996.
解放された[6]、N.、およびN.Borenstein、「マルチパーパスインターネットメールエクステンション(MIME)は2を分けます」。 「メディアタイプ」、RFC2046、1996年11月。
[7] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part
Three: Message Header Extensions for Non-ASCII Text ", RFC
2047, November 1996.
[7] ムーア、K.、「パートThreeをまねてください(マルチパーパスインターネットメールエクステンション)」 「非ASCIIテキストのためのメッセージヘッダー拡張子」、RFC2047、1996年11月。
[8] Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet
Mail Extensions (MIME) Part Four: Registration Procedures", BCP
13, RFC 2048, November 1996.
解放された[8]、N.、Klensin、J.、およびJ.ポステル、「マルチパーパスインターネットメールエクステンション(MIME)は4を分けます」。 「登録手順」、BCP13、RFC2048、1996年11月。
[9] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Five: Conformance Criteria and
Examples", RFC 2049, November 1996.
解放された[9]、N.、およびN.Borenstein、「マルチパーパスインターネットメールエクステンション(MIME)は5を分けます」。 「順応評価基準と例」、RFC2049、11月1996日
[10] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1", RFC 3501, March 2003.
[10] クリスピン、M.、「バージョン4rev1"、RFC3501、2003年インターネットメッセージアクセス・プロトコル--3月。」
Wong Informational [Page 32] RFC 4416 LEMONADE Goals February 2006
[32ページ]RFC4416レモネード目標2006年2月の情報のウォン
[11] Myers, J., "IMAP4 QUOTA extension", RFC 2087, January 1997.
[11] マイアーズ、J.、「IMAP4 QUOTA拡張子」、RFC2087、1997年1月。
[12] Hansen, T. and G. Vaudreuil, "Message Disposition
Notification", RFC 3798, May 2004.
[12] ハンセン、T.、およびG.ボードルイ(「メッセージ気質通知」、RFC3798)は2004がそうするかもしれません。
[13] Vaudreuil, G. and G. Parsons, "Voice Profile for Internet Mail
- version 2 (VPIMv2)", RFC 3801, June 2004.
[13] ボードルイ、G.、およびG.パーソンズ、「インターネットメールのためにProfileを声に出してください--バージョン2(VPIMv2)」、RFC3801、6月2004日
[14] 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.
[14] ボードルイ、G.、およびG.パーソンズ、「料金Quality Voice--32s Adaptive Differentialパルスコードの変調(ADPCM)MIME kbit/SubはRegistrationをタイプします」、RFC3802、2004年6月。
[15] Vaudreuil, G. and G. Parsons, "Content Duration MIME Header
Definition", RFC 3803, June 2004.
[15] ボードルイとG.とG.パーソンズ、「満足している持続時間MIMEヘッダー定義」、RFC3803、2004年6月。
[16] Buckley, R., Venable, D., McIntyre, L., Parsons, G., and J.
Rafferty, "File Format for Internet Fax", RFC 3949, February
2005.
[16] バックリーとR.とヴェナブルとD.とマッキンタイヤとL.とパーソンズ、G.とJ.Rafferty、「インターネットファックスのためのファイル形式」RFC3949(2005年2月)。
[17] Parsons, G. and J. Rafferty, "Tag Image File Format (TIFF) -
image/tiff MIME Sub-type Registration", RFC 3302, September
2002.
[17] パーソンズとG.とJ.Rafferty、「Image File Format(TIFF)にタグ付けをしてください--イメージ/いさかいMIMEはRegistrationをSubタイプする」RFC3302、2002年9月。
[18] Allocchio, C., "Minimal GSTN address format in Internet Mail",
RFC 3191, October 2001.
[18]Allocchio、C.、「インターネットメールにおける最小量のGSTNアドレス形式」、RFC3191、2001年10月。
[19] Allocchio, C., "Minimal FAX address format in Internet Mail",
RFC 3192, October 2001.
[19]Allocchio、C.、「インターネットメールにおける最小量のFAXアドレス形式」、RFC3192、2001年10月。
[20] Toyoda, K., Ohno, H., Murai, J., and D. Wing, "A Simple Mode of
Facsimile Using Internet Mail", RFC 3965, December 2004.
[20] 豊田、K.、大野、H.、村井、J.、およびD.は飛んで行きます、「ファクシミリの簡単なモードはインターネットメールを使用し」て、RFC3965、2004年12月。
[21] Parsons, G. and J. Rafferty, "Tag Image File Format (TIFF) - F
Profile for Facsimile", RFC 2306, March 1998.
[21] パーソンズ、G.、およびJ.Rafferty、「画像ファイル形式(いさかい)にタグ付けをしてください--ファクシミリのためのFプロフィール」、RFC2306、3月1998日
[22] Gellens, R. and J. Klensin, "Message Submission", RFC 2476,
December 1998.
[22]GellensとR.とJ.Klensin、「メッセージ提案」、RFC2476、1998年12月。
[23] Masinter, L. and D. Wing, " Extended Facsimile Using Internet
Mail", RFC 2532, March 1999.
[23] Masinter、L.、およびD.は1999年3月に「拡張ファクシミリはインターネットメールを使用すること」でのRFC2532に翼をつけさせます。
[24] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, June 1999.
[24] フィールディング、R.、Gettys、J.、ムガール人、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ・リー、「HTTP/1.1インチ、RFC2616、1999年ハイパーテキスト転送プロトコル--6月。」
[25] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April
2001.
[25]Klensin、J.、「簡単なメール転送プロトコル」、RFC2821、2001年4月。
Wong Informational [Page 33] RFC 4416 LEMONADE Goals February 2006
[33ページ]RFC4416レモネード目標2006年2月の情報のウォン
[26] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[26] レズニック、P.、「インターネットメッセージ・フォーマット」、RFC2822、2001年4月。
[27] Burger, E., Candell, E., Eliot, C., and G. Klyne, "Message
Context for Internet Mail", RFC 3458, January 2003.
2003年1月の[27] バーガーとE.とCandellとE.とエリオット、C.とG.Klyne、「インターネットメールのためのメッセージの文脈」RFC3458。
[28] Burger, E., "Critical Content Multi-purpose Internet Mail
Extensions (MIME) Parameter", RFC 3459, January 2003.
[28] バーガー、E.、「重要な満足している多目的のインターネットメール拡大(MIME)パラメタ」、RFC3459、2003年1月。
[29] Gahrns, M., "IMAP4 Multi-Accessed Mailbox Practice", RFC 2180,
July 1997.
[29]Gahrns、M.、「マルチアクセスされたメールボックスが練習するIMAP4」、RFC2180、1997年7月。
[30] Candell, E., "High-Level Requirements for Internet Voice Mail",
RFC 3773, June 2004.
[30]Candell、E.、「インターネットボイスメールのためのハイレベルの要件」、RFC3773、2004年6月。
[31] Nerenberg, L., "IMAP4 Binary Content Extension", RFC 3516,
April 2003.
[31] ネーレンバーグ、L.、「IMAP4の2進の満足している拡張子」、RFC3516、2003年4月。
[32] Nerenberg, "IMAP4 Channel Transport Mechanism", Work in
Progress, November 2001.
[32] ネーレンバーグ、「IMAP4チャンネル移送機構」は進歩、2001年11月に働いています。
[33] Toyoda, K. and D. Crocker, "SMTP Service Extensions for Fax
Content Negotiation", Work in Progress, February 2003.
[33] 「ファックスの満足している交渉のためのSMTPサービス拡張子」という豊田、K.、およびD.クロッカーは進歩、2003年2月に働いています。
[34] McRae, S. and G. Parsons, "Internet Voice Messaging (IVM)", RFC
4239, November 2005.
[34] マクレーとS.とG.パーソンズ、「インターネット声のメッセージング(IVM)」、RFC4239 2005年11月。
[35] Murchison, K. and L. Greenfield, "LMTP Service Extension for
Ignoring Recipient Quotas", Work in Progress, June 2002.
[35] 「受取人割当てを無視するためのLMTPサービス拡張子」というマーチソン、K.、およびL.グリーンフィールドは進歩、2002年6月に働いています。
[36] Crispin, M., "Message Submission", Work in Progress,
February 2004.
[36] クリスピン、M.、「メッセージ提案」が進歩、2004年2月に働いています。
[37] Newman, C., "Message Submission with Composition", Work in
Progress, February 2004.
[37] ニューマン、C.、「構成とのメッセージ提案」が進歩、2004年2月に働いています。
[38] Gellens, R., "IMAP Message Submission", Work in Progress,
December 2003.
[38] R.、「IMAPメッセージ提案」というGellensは進歩、2003年12月に働いています。
[39] Resnick, P., "Internet Message Access Protocol (IMAP) CATENATE
Extension", Work in Progress, December 2003.
[39] レズニック、P.、「インターネットメッセージアクセス・プロトコル(IMAP)カテナート拡大」が進歩、2003年12月に働いています。
[40] Crispin, M. and C. Newman, "Internet Message Access (IMAP) -
URLAUTH Extension", Work in Progress, July 2004.
[40] クリスピン、M.、およびC.ニューマン、「インターネットはアクセス(IMAP)を通信させます--URLAUTH拡張子」、進歩、2004年7月に、働いてください。
[41] Newman, D., "Message Submission BURL Extension", Work in
Progress, July 2004.
[41] ニューマン、D.、「メッセージ服従節拡張子」が進歩、2004年7月に働いています。
Wong Informational [Page 34] RFC 4416 LEMONADE Goals February 2006
[34ページ]RFC4416レモネード目標2006年2月の情報のウォン
[42] Crocker, D., "Internet Mail Architecture", Work in Progress,
July 2004.
[42] クロッカー、D.、「インターネットメールアーキテクチャ」が進歩、2004年7月に働いています。
[43] Leuca, I., "Multimedia Messaging Service", Presentation to the
VPIM WG, IETF53 Proceedings , April 2002.
[43]Leuca、I.、「マルチメディア・メッセージング・サービス」、VPIM WGへのプレゼンテーション、IETF53議事、2002年4月。
[44] Mahy, R., "A Message Summary and Message Waiting Indication
Event Package for the Session Initiation Protocol (SIP)", RFC
3842, August 2004.
[44] マーイ、R.、「セッション開始のためのメッセージ概要とメッセージ待ち指示イベントパッケージは(一口)について議定書の中で述べます」、RFC3842、2004年8月。
[45] Shapira, N. and E. Aloni, "Simple Notification and Alarm
Protocol (SNAP)", Work in Progress, December 2001.
[45] 「簡単な通知とアラームプロトコル(折る)」というシャピーラ、N.、およびE.Aloniは進歩、2001年12月に働いています。
[46] Vaudreuil, G., "Messaging profile for telephone-based Messaging
clients", Work in Progress, February 2002.
[46] G. ボードルイ、Progress、2002年2月の「電話ベースのMessagingクライアントのためにプロフィールを通信する」Work。
[47] Burger, E., "Internet Unified Messaging Requirements", Work in
Progress, February 2002.
[47] バーガー、E.、「インターネットユニファイド・メッセージング要件」が進歩、2002年2月に働いています。
[48] OMA, "Multimedia Messaging Service Architecture Overview
Version 1.1", Open Mobile Alliance (OMA) OMA-WAP-MMS-ARCH-v1_1-
20021101-C, November 2002.
[48] OMA、「マルチメディアメッセージサービスアーキテクチャ概要バージョン1.1インチ、1- 20021101Cと、2002年11月にモバイル同盟(OMA)OMAワップ-MMS大-v1の_を開いてください。」
[49] OMA, "Push Architectural Overview", Open Mobile Alliance
(OMA) WAP-250-PushArchOverview-20010703-a, July 2001.
[49] 「プッシュの建築概要」というOMAはモバイル同盟(OMA)WAP-250-PushArchOverview-20010703-a、2001年7月を開きます。
[50] OMA, "Push Access Protocol Specification", Open Mobile Alliance
(OMA) WAP-247-PAP-20010429-a, April 2001.
[50] 「プッシュアクセスプロトコル仕様」というOMAは2001年4月にモバイル同盟(OMA)WAP247乳首20010429-aを開きます。
[51] OMA, "Push Proxy Gateway Service Specification", Open Mobile
Alliance (OMA) WAP-249-PPGService-20010713a, July 2001.
[51] 「プッシュプロキシゲートウェイサービス仕様」というOMAはモバイル同盟(OMA)WAP-249-PPGService-20010713a、2001年7月を開きます。
[52] OMA, "Multimedia Messaging Service; Client Transactions Version
1.1", Open Mobile Alliance
(OMA) OMA-WAP-MMS-CTR-v1_1-20021031-C, October 2002.
[52] OMA、「マルチメディア・メッセージング・サービス」。 クライアントトランザクションバージョン1.1インチ、OMA-WAP-MMS-CTR-v1_1-20021031Cと、2002年10月にモバイル同盟(OMA)を開いてください。
[53] OMA, "Multimedia Messaging Service; Encapsulation Protocol
Version 1.1", Open Mobile Alliance (OMA) OMA-MMS-ENC-v1_1-
20021030-C, October 2002.
[53] OMA、「マルチメディア・メッセージング・サービス」。 カプセル化はバージョン1.1インチと、開いているモバイル同盟(OMA)OMA-MMS-ENC-v1_1- 20021030Cと、2002年10月に議定書を作ります。
[54] OMA, "User Agent Profile, Version 1.1", Open Mobile Alliance
(OMA) OMA-UAProf-v1_1-20021212-C, December 2002.
「エージェントのプロフィールのバージョン1.1インチ開いているモバイル同盟(OMA)OMA-UAProf-v1_1-20021212ユーザCと、2002年12月」の[54]OMA。
[55] OMA, "Email Notification Version 1.0", Open Mobile Alliance
(OMA) OMA-EMN-v1_0-20021031-C, October 2002.
[55] OMA、「通知バージョン1インチと、開いているモバイル同盟(OMA)OMA-EMN-v1_0-20021031Cと、2002年10月に、メールしてください。」
Wong Informational [Page 35] RFC 4416 LEMONADE Goals February 2006
[35ページ]RFC4416レモネード目標2006年2月の情報のウォン
[56] 3GPP, "Third Generation Partnership Project; Technical
Specification Group Services and System Aspects; Service
aspects; Functional description; Stage 1 Multimedia Messaging
Service", 3GPP TS 22.140, 2001.
[56]3GPP、「第三世代パートナーシッププロジェクト」。 仕様書グループサービスとシステム局面。 局面を修理してください。 機能的な記述。 「ステージ1マルチメディアメッセージサービス」、3GPP t22.140、2001。
[57] 3GPP, "Third Generation Partnership Project; Technical
Specification Group Terminals; Multimedia Messaging Service
(MMS); Functional description; Stage 2", 3GPP TS 23.140, 2001.
[57]3GPP、「第三世代パートナーシッププロジェクト」。 仕様書グループ端末。 マルチメディア・メッセージング・サービス(MMS)。 機能的な記述。 2インチ、3GPP t23.140、2001を上演してください。
[58] 3GPP2, "Short Message Service (SMS)", 3GPP2 TSG C.S0015-0,
December 1999.
1999年12月の[58]3GPP2、「短いメッセージサービス(SMS)」3GPP2 TSG C.S0015-0。
[59] 3GPP2, "Enhanced Message Service (EMS) Stage 1 Description",
3GPP2 TSG S.R0051-0 v1.0, July 2001.
[59]3GPP2、「ステージ1つの高められたメッセージサービス(EMS)記述」、3GPP2 TSG S.R0051-0 v1.0、2001年7月。
[60] CCITT, "Recommendations Q.700-Q.716: Specifications of
Signalling System No. 7", CCITT White Book, Volume VI,
Fascicle VI.7.
[60] CCITT、「推薦Q.700-Q.716:」 合図システムNo.7インチの仕様、CCITT白書、巻VI、分冊VI.7。
[61] CCITT, "Recommendations Q.721-Q.766: Specifications of
Signalling System No.7", CCITT White Book, Volume VI,
Fascicle VI.8.
[61] CCITT、「推薦Q.721-Q.766:」 合図システムNo.7インチの仕様、CCITT白書、巻VI、分冊VI.8。
[62] ITU, "E.164: The international public telecommunication
numbering plan", ITU-T Recommendations Series E, May 1997.
[62] ITU、「E.164:」 「国際的な公共の電気通信付番プラン」、ITU-T Recommendations Series E、1997年5月。
[63] ITU, "Specifications of Signalling System Number 7", ITU White
Book, ITU-T Recommendation Q.763.
[63]ITU、「合図システム数の7インチの仕様、ITU白書、ITU-T推薦Q.763。」
[64] ITU, "Interface between Data Terminal Equipment (DTE) and Data
Circuit-terminating Equipment (DCE) for terminals operating in
the packet mode and connected to public data networks by
dedicated circuit", ITU-T Recommendation X.25, October 1996.
[64] ITU-T Recommendation X.25、1996年10月、「パケット形態で作動して、Data Terminal Equipment(DTE)とData Circuit-終わりEquipment(DCE)の間で端末に連結して、専用回路によって公衆データネットワークに関連づけられた」ITU。
[65] BELLCORE, "Specifications of Signalling System Number 7", GR-
246-CORE Issue 1, December 1994.
[65] Bellcore、「合図システム数の7インチの仕様、GRの246中核となる問題の1、1994年12月。」
Wong Informational [Page 36] RFC 4416 LEMONADE Goals February 2006
[36ページ]RFC4416レモネード目標2006年2月の情報のウォン
Appendix A. Contributors
付録A.貢献者
Eric Burger Brooktrout Technology, Inc. 18 Keewaydin Dr. Salem, MA 03079 USA
エリックバーガーBrooktrout技術Inc.18Keewaydin礼拝堂MA03079博士(米国)
Phone: +1 603 890-7587 EMail: eburger@brooktrout.com
以下に電話をしてください。 +1 603 890-7587 メールしてください: eburger@brooktrout.com
Yair Grosu Comverse 29 Habarzel St. Tel-Aviv 69710 Israel
Yair Grosu Comverse29Habarzel聖テルアビブ69710イスラエル
EMail: Yair.Grosu@comverse.com
メール: Yair.Grosu@comverse.com
Glenn Parsons Nortel Networks P.O. Box 3511 Station C Ottawa, ON K1Y 4H7 Canada
グレンノーテル教区牧師は私書箱3511駅のCオタワをK1Y 4H7カナダにネットワークでつなぎます。
Phone: +1 613 763-7582 EMail: gparsons@nortelnetworks.com
以下に電話をしてください。 +1 613 763-7582 メールしてください: gparsons@nortelnetworks.com
Milt Roselinsky Openwave Systems, Inc. 530 E. Montecito St. Santa Barbara, CA 93103 USA
脾臓Roselinsky Openwave Systems Inc.530E.Montecito聖サンタバーバラ(カリフォルニア)93103米国
Phone: +1 805 884-6207 EMail: milt.roselinsky@openwave.com
以下に電話をしてください。 +1 805 884-6207 メールしてください: milt.roselinsky@openwave.com
Dan Shoshani Comverse 29 Habarzel St. Tel-Aviv 69710 Israel
ダンShoshani Comverse29Habarzel聖テルアビブ69710イスラエル
EMail: Dan.Shoshani@comverse.com
メール: Dan.Shoshani@comverse.com
Wong Informational [Page 37] RFC 4416 LEMONADE Goals February 2006
[37ページ]RFC4416レモネード目標2006年2月の情報のウォン
Alan K. Stebbens Openwave Systems, Inc. 530 E. Montecito St. Santa Barbara, CA 93103 USA
アランK.Stebbens Openwave Systems Inc.530E.Montecito聖サンタバーバラ(カリフォルニア)93103米国
Phone: +1 805 884-3162 EMail: alan.stebbens@openwave.com
以下に電話をしてください。 +1 805 884-3162 メールしてください: alan.stebbens@openwave.com
Gregory M. Vaudreuil Lucent Technologies 7291 Williamson Rd. Dallas, TX 75214 USA
グレゴリーM.ボードルイルーセントテクノロジーズ7291ウィリアムソン通り ダラス、テキサス75214米国
Phone: +1 214 823-9325 EMail: GregV@ieee.org
以下に電話をしてください。 +1 214 823-9325 メールしてください: GregV@ieee.org
Appendix B. Acknowledgements
付録B.承認
Ari Erev and Noam Shapira (both from Comverse) contributed substantial requirements for IMAP to support a telephone-based (TUI) messaging client. Meir Mendelovich (Comverse) helped in merging the wireless requirements section. Benjamin Ellsworth (Openwave) contributed to mobile messaging architectures and requirements. Yaacov (Jerry) Weingarten (Comverse) and Stephane Maes (Oracle) provided detailed comments on the final document.
IMAPが電話ベースの(TUI)メッセージングクライアントをサポートするというアリErevとノーム・シャピーラ(Comverseからの両方)の寄付されたかなりの要件。 メイアMendelovich(Comverse)は、ワイヤレスの要件部を合併するのを手伝いました。 ベンジャミン・エルズワース(Openwave)はモバイルメッセージングアーキテクチャと要件に貢献しました。 ヤーコブ(ジェリー)のヴェンガルデン(Comverse)とステファーヌMaes(オラクル)は最終合意文書の詳細なコメントを提供しました。
Appendix C. IAB Note: Unified Notification Protocol Considerations
付録C.IABは以下に注意します。 統一された通知プロトコル問題
Note: dated July 10, 2003
以下に注意してください。 2003年7月10日に、デートします。
This note was formulated in response to an informal IESG request to
look at the architectural issues surrounding a unified notification
protocol. The following materials were used as reference:
* draft-dusseault-s2s-event-reqs-00.txt (notification
requirements)
* meeting notes for the LEMONADE WG from IETF 56.
* draft-shapira-snap-05.txt (protocol design for SNAP which has
some aspects of a generic notification protocol)
* the LEMONADE WG charter
* Recent email on the Lemonade list
* A few presentations from the 1998 UCI workshop on Internet-wide
notification
この注意は構造的な問題が統一された通知プロトコルを囲むのを見るという非公式のIESG要求に対応して定式化されました。 以下の材料は参照として使用されました: * IETF56からのLEMONADE WGのための草稿dusseault-s2sイベントreqs-00.txt(通知要件)*ミーティング注意。 * shapiraスナップ05.txtを作成してください、(ジェネリック通知プロトコル) LEMONADE WGがチャーターする*のいくつかの局面を*最近にするSNAPのためのプロトコルデザインはLemonadeリスト*で広さのインターネット通知に関する1998UCIワークショップからいくつかのプレゼンテーションをメールします。
Wong Informational [Page 38] RFC 4416 LEMONADE Goals February 2006
[38ページ]RFC4416レモネード目標2006年2月の情報のウォン
* The Web pages for KnowHow, a company founded by Rohit Khare
which has a proprietary Internet-wide notification system.
* KnowHowのためのウェブページ、独占インターネット全体の通知システムを持っているRohit Khareによって設立された会社。
Thanks to Lisa Dusseault for providing these references.
これらの参照をリサDusseaultに提供してくださってありがとうございます。
Note that this opinion does not represent IAB concensus, it is just the opinion of the author after having reviewed the references.
この意見がIAB concensusを表さないというメモ、それはただ参照を再検討した後の作者の意見です。
After the reviewing the material, it seemed that the same kinds of functionality are being asked from a generic notification protocol as are asked of desktop application integration mechanisms, like OLAY/ COM on Windows or like Tooltalk was on Solaris, but at the level of messaging across the Internet. The desire is that various distributed applications with different application specific mechanisms should be able to interoperate without having an n x n problem of having each application interact with each other application. The cannonical example, which is in a presentation by Lisa Dusseault to LEMONADE from IETF 56, is sending a notification from one application, like XMPP Instant Messaging, and having it delivered on whatever device the recipient happened to be using at the time, like SMS on a cell phone.
材料であり論評の後に、それは見えました。そんなに同じ種類の機能性は、Tooltalkにデスクトップアプリケーション統合メカニズムに尋ねられるジェネリック通知プロトコルから尋ねられていたか、オーレイ/COMがWindowsで好きであった、Solarisの上にありましたが、またはインターネットの向こう側に通信するレベルで似ていました。 願望は特定のメカニズムが各アプリケーションを持っているというn x n問題を持っていなくて共同利用するはずであることができる異なったアプリケーションによる様々な分配されたアプリケーションが互いに伴うアプリケーションを相互作用させるということです。 cannonicalの例(IETF56からのLEMONADEにはリサDusseaultによるプレゼンテーションである)で、XMPP Instant Messagingのように1つのアプリケーションから通知書を送っていて、受取人がたまたま当時、使用していたどんなデバイスでもそれを提供しています、携帯電話の上のSMSのように。
The usual problem with application intergration mechanisms on the desktop is how to get the various applications to actually use the mechanism. For Windows, this is relatively easy, since most application developers see major value-added in their applications being able to play nicely with Microsoft Office. For Tooltalk, unfortunatly, Solaris developers didn't see the 10x improvement, and so it was not used outside of Sun's internally maintained applications and a few flagship applications like Framemaker. If the generic notification mechanism requires application developers and other notification protocol designers to make a major effort to utilize it, including modifying their applications or protocols in some way, the protocol could become "just another notification mechanism" rather than a unifying device, because most application developers and other protocol designers could ignore it.
デスクトップのアプリケーションintergrationメカニズムに関する普通の問題は様々なアプリケーションに実際にメカニズムをどう使用させるかということです。 Windowsに、これは比較的簡単です、ほとんどのアプリケーション開発者が、彼らのアプリケーションで付加価値が付いた少佐がうまくマイクロソフトオフィスにプレーできるのを見るので。 Tooltalkに関しては、unfortunatlyに、Solaris開発者は10x改良を見ませんでした、そして、したがって、それはSunの内部的に維持されたアプリケーションの外で使用されませんでした、そして、いくつかの最高級品アプリケーションがFramemakerが好きです。 ジェネリック通知メカニズムが、アプリケーション開発者と他の通知プロトコルデザイナーが何らかの方法で彼らのアプリケーションかプロトコルを変更するのを含むそれを利用するために主要な取り組みを作るのを必要とするなら、プロトコルは統一デバイスよりむしろ「ただの通知メカニズム」になるかもしれません、ほとんどのアプリケーション開発者と他のプロトコルデザイナーがそれを無視できたので。
So the first architectural consideration is how do clients of a particular protocol (and the word "client" is used here to mean "any entity using the protocol", they may peers or they may be client/server) actually utilize the generic notification protocol? Is there some code change required in the client or can a legacy client interoperate without change?
したがって、最初の建築考慮はどのようにがするかということです。特定のプロトコル(「どんな実体もプロトコルを使用し」て、彼らが使用することを意味するのにおいて「クライアント」がここで使用されているという単語はじっと見るか、彼らはクライアント/サーバであるかもしれない)のクライアントは実際にジェネリック通知プロトコルを利用しますか? クライアントで必要であるいくらかのコード変遷がありますか、レガシークライアントは変化なしで共同利用できますか?
If you look at Fig. 1 in draft-shapira-snap-05.txt, the answer seems to be that the notifying client uses the generic protocol, SNAP in this case, to a functional entity (server? module on the receiving client?) called the "Notification Service" that processes the generic
あなたが草稿shapira即座の05.txtの図1を見るなら、答えは通知しているクライアントがジェネリックプロトコルを使用するということであるように思えます、この場合、SNAP、ジェネリックを処理する「通知サービス」と呼ばれる機能的な実体(サーバ--受信クライアントの上のモジュール?)に
Wong Informational [Page 39] RFC 4416 LEMONADE Goals February 2006
[39ページ]RFC4416レモネード目標2006年2月の情報のウォン
notification into an application specific notification and sends that notification to the client. From this figure it looks as if the notifying client would require modification but the receiving client wouldn't.
そして、アプリケーションの特定の通知への通知、その通知をクライアントに送ります。 この図から、まるで通知しているクライアントが変更を必要とするかのように見えますが、受信クライアントは見えないでしょう。
Another characteristic of application integration mechansims is that they typically focus on very simple operations, the semantics of which are shared between different applications. Examples are "here's a rectangle, display yourself in it" or "put this styled text object into the clipboard", and applications agree on what styled text means. More complicated semantics are hard to share because each application has its own particular twist on the meaning of a particular sequence of operations on a collection of objects. The result is a "least common denominator" collection of integration mechanisms, primarily focussed on display integration and, to a lesser extent, cut and paste integration.
それらが非常に簡単な操作、意味論に通常集中するアプリケーション統合mechansimsの別の特性はあります(異なったアプリケーションの間で共有されます)。 例は、「ここに、長方形、ディスプレイがそれに自分である」か、「この流行に合わせられたテキストオブジェクトをクリップボードに入れてください」です、そして、アプリケーションはテキスト手段を流行に合わせたことに同意します。 各アプリケーションが操作の特定の系列の意味にそれ自身の特定のねじれをオブジェクトの収集に持っているので、より複雑な意味論は共有しにくいです。 結果は統合メカニズム、主として焦点を合わせられたディスプレーされた統合、およびある程度カットアンドペースト統合の「共通項」収集です。
In the context of a generic notification protocol, this raises several possible issues. One is addressing, which is identified draft-dusseault-s2s-event-reqs-00.txt, but in a sense this is the easiest to resolve, by using existing and perhaps newly defined URIs. A more complex problem is matching the semantics of what preconditions constitute the trigger for an event across different application notification mechanisms. This is of course necessary for translating notifications between the different event notification mechanisms and the generic mechanism, but, more problematically, it is also required for a subscription service whereby subscriptions can be made to filter events using the generic notification mechanism and the subscriptions can be translated to different application specific mechanisms. Any language for expressing generic subscriptions is unlikely to support expressing the fine points in the different application notification semantics. Note that SNAP does not seem to support a subscription service so perhaps this isn't an issue for SNAP.
ジェネリック通知プロトコルの文脈では、これはいくつかの可能な問題を提起します。 1つはアドレシングですが、ある意味で、これは最も決議しやすいです、既存の、そして、恐らく新たに定義されたURIを使用することによって。(アドレシングは特定された草稿dusseault-s2sイベントreqs-00.txtです)。 より複雑な問題はどんな前提条件がイベントのために異なったアプリケーション通知メカニズムの向こう側に引き金を構成するかに関する意味論に合っています。これがもちろん異なったイベント通知メカニズムとジェネリックメカニズムの間の通知を翻訳するのに必要です; しかし、また、より問題として、ジェネリック通知メカニズムを使用することでイベントをフィルターにかけるのを購読をすることができる購読サービスのためにそれを必要とします、そして、異なったアプリケーション特定のメカニズムに購読を翻訳できます。ジェネリック購読を言い表すためのどんな言語も、異なったアプリケーション通知意味論で言い表すのが委細であるとサポートしそうにはありません。 これが恐らくSNAPのための問題でないためにSNAPが、購読がサービスであるとサポートするように思えないことに注意してください。
Another architectural issue, which was discussed earlier this year on the LEMONADE list w.r.t. some other topics, is gatewaying. The cannonical example above (message sent using XMPP and arriving via SMS on a cell phone) is actually a gateway example, because it would require translation between an IP-based messaging mechanism (XMPP) to a PSTN based mechanism (SMS). The problem with using a unified notification mechanism for this purpose is that if there are other functions common between the two, it is likely that a gateway will be built anyway. In fact, one of the work items for LEMONADE is to investigate such gateways. The value of a generic notification mechanism therefore needs to be assessed in the light of this.
別の構造的な問題(LEMONADEに、w. r. t. ある他の話題が記載しているこの年により早く議論した)はgatewayingされています。 (携帯電話の上のSMSを通してXMPPを使用して、到着するのが送られたメッセージ)を超えたcannonicalの例は実際にゲートウェイの例です、IPベースのメッセージングメカニズム(XMPP)の間の翻訳をPSTNのベースのメカニズム(SMS)に必要とするでしょう、したがって。 統一された通知メカニズムを使用することに関する問題はこのために2つの間で一般的な他の機能があると、ゲートウェイがとにかく建設されそうであるということです。 事実上、LEMONADEのための仕事項目の1つはそのようなゲートウェイを調査することです。 したがって、ジェネリック通知メカニズムの値は、これの見地から評価される必要があります。
Wong Informational [Page 40] RFC 4416 LEMONADE Goals February 2006
[40ページ]RFC4416レモネード目標2006年2月の情報のウォン
These are the primary architectural issues, but there are a few others that need consideration in any major system development effort. End to end security is one, draft-dusseault-s2s-event-reqs-00.txt talks about this quite extensively, so it won't be repeated here. The major issue is how to ensure that the end to end security properties are maintained in the face of movement of the notification through the generic intermediary protocol. Another issue is scalability. Peer to peer v.s. server based mechanisms have implications for how scalable the notification mechanism would be, and this needs consideration. Extensibility needs careful consideration. What is required to integrate a new application? Ideally, with time, application developers will stop "rolling their own" notification service and simply use the generic service, but this ideal may be extremely hard to achieve, and may depend to a large extent on market acceptance.
これらは第一の構造的な問題ですが、どんな主要なシステム開発努力でも考慮を必要とする数人の他のものがいます。 セキュリティを終わらせる終わりが1である、草稿dusseault-s2sイベントreqs-00.txtはこれに関して全く手広く話して、したがって、それはここで繰り返されないでしょう。 主要な問題はその終わりから終わりにセキュリティの特性が一般的な仲介者プロトコルを通した通知の動きに直面して維持されるのをどう保証するかということです。 別の問題はスケーラビリティです。 ピアツーピアv.s.サーバに基づいているメカニズムには、通知メカニズムがどれくらいスケーラブルであるか意味があります、そして、これは考慮を必要とします。 伸展性は熟慮を必要とします。 何が、新しいアプリケーションを統合するのに必要ですか? アプリケーション開発者が時間と共に、理想的に、「それら自身回転しているの」通知サービスを止めて、一般的なサービスを単に利用しますが、この理想は、達成するのが非常に困難であるかもしれなく、大体において市場承認によるかもしれません。
Finally, there are some considerations that aren't architectural but may impact the ultimate success of a generic notification protocol, in the sense that the protocol becomes widely deployed and used. The author's experience is that IETF has not had particular success in introducing mechanisms that unify or supplant existing proprietary mechanisms unless strong vendor and service provider by-in is there. Two examples are instant messaging and service discovery. With instant messaging, it seems that a standarized, unified instant messaging protocol has been delayed by the lack of committment from major service providers. With service discovery, weak commitment from vendors has resulted in the continued introduction of vendor specific service discovery solutions even after an IETF standard is in place. The situation with service discovery (with which the author is most familiar) resulted from a lack of major vendor committment during the end phases of the standarization process. Applying these lessions to a generic notification protocol, having important players with proprietary notification protocols on board and committed until the conclusion of the design process will be crucial. Major committment is needed from various application notification protocols before a generic mechanism could succeed. Given the amount of time and effort required in any IETF standardization work, assessing these with an objective eye is critical, otherwise, regardless of how technically well designed the protocol is, deployment success may be lacking. Having an elegently design solution that nobody deploys is an outcome that might be wise to avoid.
最終的に、一般的な通知プロトコルの終局の成功は、いくつかの建築していない問題ですが、影響を与えるかもしれません、プロトコルが広く配備されていて使用されるようになるという意味で。 作者の経験は強い業者とサービスプロバイダーがそこにコネで持っていない場合IETFには特定の成功が既存の独占メカニズムに統一するか、または取って代わるメカニズムを紹介するのをないということです。 2つの例は、インスタントメッセージングとサービス発見です。 インスタントメッセージングで、standarizedされて、統一されたインスタントメッセージングプロトコルがcommittmentの不足で主要サービスプロバイダーから遅れたように思えます。 サービス発見で、IETF規格が適所にありさえした後にさえ業者からの弱い委任は業者の特定のサービス発見対策の継続的な導入をもたらしました。 サービス発見(作者が最も詳しい)がある状況はstandarizationの過程の終わりの段階の間、一流の業者committmentの不足から生じました。 一般的な通知プロトコルにこれらのlessionsを適用して、デザイン過程の結論まで独占通知プロトコルをもっている重要な立役者がいて、公約するのは重要でしょう。 一般的なメカニズムが成功できる前に主要なcommittmentが様々なアプリケーション通知プロトコルから必要です。 どんなIETF標準化仕事でも必要である時間と努力を考えて、客観的な目でこれらを評価するのが批判的である、さもなければ、どれくらい技術的によく設計されているかにかかわらずプロトコルがあって、展開成功は欠けているかもしれません。 だれも配備しないelegentlyデザイン解決を持つのは、避けるために賢明であるかもしれない結果です。
James Kempf July 2003
ジェームスケンフ2003年7月
Wong Informational [Page 41] RFC 4416 LEMONADE Goals February 2006
[41ページ]RFC4416レモネード目標2006年2月の情報のウォン
Author's Address
作者のアドレス
Jin Kue Wong (Editor) Nortel Networks P.O. Box 3511 Station C Ottawa, ON K1Y 4H7 Canada
チンKue Wong(エディタ)ノーテルは私書箱3511駅のCオタワをK1Y 4H7カナダにネットワークでつなぎます。
Phone: +1 613 763-2515 EMail: j.k.wong@sympatico.ca
以下に電話をしてください。 +1 613 763-2515 メールしてください: j.k.wong@sympatico.ca
Wong Informational [Page 42] RFC 4416 LEMONADE Goals February 2006
[42ページ]RFC4416レモネード目標2006年2月の情報のウォン
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Wong Informational [Page 43]
ウォン情報です。[43ページ]
一覧
スポンサーリンク
