Network Working Group J. Wong, Ed.
Request for Comments: 4416 Nortel Networks
Category: Informational February 2006
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).
著作権（C）インターネット協会（2006）。
Abstract
抽象
This document is a history capturing the background, motivation and thinking during the LEMONADE definition and design process.
この文書では、レモネードの定義と設計プロセス中に背景、動機や思考を捉える歴史です。
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メールプロトコルを使用して、モバイルハンドヘルドデバイスにインターネットメールへの限界のないアクセスを許可する - インターネットメールプロトコルは、より豊かで多様なメディアや環境へのより適応することによって。
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.
これらのデバイスのための要件は、多様なサービス環境に限定された機能のホスト上のマルチメディアメッセージングをサポートするために必要な可能なプロトコルの拡張の議論を推進します。強化されたメッセージング・プロトコルの設計を導くための一般原則のリストが記載されています。最後に、強化されたインターネットメールと既存の別のモバイルメッセージングインフラストラクチャとのシームレスなサービスを提供する追加の問題を簡単に記載されています。
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
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
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のインターネットメールシステムは、（[4]、[10]、[25]）は、リッチテキストに加えて、添付ファイルからなるメッセージをネットワークに接続されたコンピュータをサポートするために進化しました。 Oボイスメールシステムは、電話ベースまたはユーザインターフェイスの留守番スタイルでクライアントを利用しました。電話網は、録音された音声メッセージを輸送するために使用しました。修正電話ベースのインタフェースを使用して、ファックス機とOファックスストアアンドフォワードのユーザー・インターフェース。ファックス機はモデム経由でFAXデータの輸送のための電話網を使用しています。 OのSMS（ショートメッセージサービス）[58]は輸送のために（[65]、[60]、[61]、[63]、[64]）SS7呼制御インフラストラクチャを使用して自分の携帯電話間の短いテキストメッセージを送信するユーザーを有効に。
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.
MIMEによりO（[5]、[6]、[7]、[8]、[9]、[28]）は、インターネット・メール・トランスポートは、拡張によってプロファイルしたデジタルデータOインターネットメールプロトコルのいずれかの種類を運ぶために強化されましたVPIM（[13]、[14]、[15]、[34]）とiFAXの（[16]、[17]、[18]、[19]、[20]、[21]、[23]）がその有効なボイスメールシステムやファックスは、電話網に代わるものとして、インターネット上で自分のメッセージを伝えるために、共通の電子メールインフラストラクチャを使用することができます。これらの拡張機能は、信頼性、セキュリティ、および応答性のユーザの経験は、インターネット経由で輸送によって減少しなかったようでした。
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努力 - インターネット電子メールは、多様なサービス環境をサポートするために - モバイルデバイス用のインターネットメールのサポートを有効にすると、既存のモバイルメッセージング宇宙との相互運用性を促進することにより、さらにこのビジョンを実現しています。
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は、EMS（拡張メッセージ・サービス）[59]が可能に長いテキストメッセージ、画像、グラフィックスに強化されました。より豊富な機能セットと、MMS（マルチメディアメッセージングサービス）（[43]、[52]、[53]、[56]、[57]）画像、音声を伝送するための軽量のアクセスメカニズムとして開発された、そして映画。 MMSプロトコルはインターネット標準（メッセージングとウェブ[24]の両方）だけでなく、SMSに一部基づいています。携帯メッセージングの世界には、特別な環境にタイムリーかつ効果的な方法で適切な機能を提供するようになって別のインフラストラクチャです。 Oだけでなく、サポートする必要が異なるモバイルクライアントの数が増殖し続けます。 （例えば、携帯電話以外にワイヤレス対応の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 - ユーザインタラクションのワイヤレスユーザーインターフェース（WUI）モードは、モバイルワイヤレスハンドヘルド動作環境の制約によって決定されます。 O電話ベースの音声クライアント - 電話ユーザーインターフェイス（TUI）、これは設定POTSによって提供されるユーザー・モードである*これは、WUIのサブセットであり、他のコンテキストで有用です。 Oマルチモーダルメッセージングクライアントを同時に表示し、オーディオモードを使用して協調メッセージングセッションを提供します。 （例えば、携帯電話とPCとからなるシステム、または音声回路及び調整を必要とするデータチャネルの両方を備えた無線電話）。 *これはまた、WUIのサブセットであり、他のコンテキストで有用です。
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の原則のリストには、多様なサービス環境のためのインターネットメッセージングの設計を導くために使用されます。 WUIsをサポートするためのインターネット・メール・プロトコルの拡張でO詳細な議論。強化されたインターネットメールの相互運用および既存のモバイルメッセージングサービスに関連するいくつかの問題、O。
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"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります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]を参照してください。
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.
二つの基本的なトランザクションのモデルがあります。 「プル」モデルでは、コンポーネントではなく、データフロー、トランザクションを開始します。例えば、クライアントは、着信メッセージを配信するために、サーバーへのサーバーと問題の要求への接続を開始することができます。従来の電子メールクライアント、ウェブメールクライアント、および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.
「プッシュ」モデルは、トランザクションを開始するコンポーネントがあるため、それに影響を与えるいくつかのデータの流れのようにしている点が異なります。例えば、終端サーバーで新規メッセージの到着は、メッセージングクライアントに（「プッシュ」）通知が送信される可能性があります。
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
| |
+------+
Simple Messaging Model
単純なメッセージングモデル
"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.
「提出」クライアントと元のユーザーが別のユーザーに新しいメッセージを送信することにより、サーバー間のトランザクションです。提出は、クライアントからサーバーへのプッシュです。
"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.
「通知」サーバがそのクライアントのために意図されたメッセージを受信したことをクライアントに通知することにより、トランザクションです。通知は、サーバからクライアントへのプッシュです。
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.
インターネットメールは、それはまだ標準化された通知プロトコルの必要性を見ていないという点で異なります。
"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.
プルモデル、（モバイルまたは従来の）ほとんどのシステムで実装は、ユーザが実際に送信され、クライアントによって保存されているどのデータを制御することができるという利点を有します。
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.
インターネットメッセージングは、従来の電子メール以外のクライアントとサーバーの種類の様々なサポートするために行うことができます。クライアントはまた、クライアントが異なる機能に適合させることができるなど限られた処理能力、メッセージストア、表示ウィンドウサイズ、ホストの制限に適合させることができる（例えば、ボイスメール、ファックス、等）。サーバは別のメディア（例えば、ボイスメール、ファックス、ビデオなど）の優れたハンドリングを可能にするオプションのメール機能をサポートすることができます。特定のアプリケーションのニッチをサポートするインターネットメールプロファイルの数は、定義されたか、提案されています。
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を除き、彼らは、クライアントからサーバーへの対話には対応していません。
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にRFC3801 [13] [15]は、インターネットのメールシステムを使用して音声メッセージの輸送を可能にします。この作業のための主要なドライバは、ボイスメールシステムのためのIPトランスポートのサポートでした。ボイス・メール・クライアントは、メッセージ配信のような応答性とより確実に慣れているように、VPIMv2によって追加された機能はメッセージ気質を含みます
Notification and Delivery Status Message ([12], [3]). Voice media has also been added to multi-part message bodies.
通知および配信ステータスメッセージ（[12]、[3]）。音声メディアは、マルチパートメッセージ本文に追加されました。
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.
プロファイルのこのセット（[16]、[17]、[18]、[19]、[20]、[21]）はインターネットメールプロトコルを使用してファックスの輸送を可能にします。この作品は、画像/ TIFFのMIMEタイプを定義しました。ファックスクライアントのサポートもメッセージ配信通知の拡張を必要としていました。
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.
（その要件RFC 3773に記載されている[30]）、この提案されたメール拡張機能は、ボイスメールをサポートするシステムにおける多様なコンポーネント（クライアントならびにサーバ）との間のボイスメッセージの交換のためのサポートをターゲット。
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を実施し、現在のボイスメールシステムのアーキテクチャを表しています。
|-------------|
|-------| RFC-822/MIME | |
| | |---------------------------| MTA |
| | | mail submission -> | |(E)SMTP
Telephone--|TUI|TUA| |------| |-----to
| | | Proprietary Protocol | | |another
| | |---------------------------| MS | | email
|-------| < - mail retrieval | | | server
|-------------|
mail client email server
|----------------voice messaging system -------------|
Mail client consists of: TUI (Telephone User Interface) and TUA (Telephone User Agent)
TUI（電話ユーザインターフェイス）とTUA（電話ユーザーエージェント）：メールクライアントの構成要素は
Communication between TUI and TUA is proprietary.
TUIとTUA間の通信は独自のものです。
Email server consists of: MS (Mail Store) and MTA (Message Transfer Agent)
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:
独自のプロトコルは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
|- voice mail system-| |-mail server-|
| - ボイスメールシステム - | | -mailサーバ - |
Mail client consists of: TUI (Telephone User Interface) and TUA (Telephone User Agent)
TUI（電話ユーザインターフェイス）とTUA（電話ユーザーエージェント）：メールクライアントの構成要素は
Communication between TUI and TUA is proprietary.
TUIとTUA間の通信は独自のものです。
Email server consists of: MS (Mail Store) and MTA (Message Transfer Agent)
MS（メールストア）とMTA（メッセージ転送エージェント）：メールサーバの構成要素は
Communication between MS and MTA is proprietary.
MSとMTA間の通信は独自のものです。
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.
マルチモーダルクライアントは、ユーザーとの対話の協調音声およびデータモードの利点を提供します。 1 TUIクライアント、他の単純なGUIクライアント - アーキテクチャ、マルチモーダルクライアントは、労働組合の2つのユーザー・エージェント・コンポーネントと考えることができます。次の図を参照してください。グラフィカル・ユーザー・エージェント（GUA）電話ユーザエージェント（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.)
このモデルは、歴史的に、彼らは、データチャネルを添加した携帯電話から進化しているため、携帯機器は、データアクセスをサポートして当たり前です。相互作用の複数の補完的なモードのプレゼンテーションでは、エンドユーザーが特定のタスクのための最も便利で自然な動作モードの彼らの選択を提供します。マルチモーダルモデルが適切である他の状況があります。 （例えば、電話販売ユニットは、一体的に同時に音声（電話）モードとの相互作用の従来のデスクトップPCモードを提供する必要があります。）
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で限られた範囲にレモネードによって対処されます。
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.
ワイヤレスユーザーインターフェイスは、個人のワークステーション上で、従来の電子メールクライアントと機能的に同等であるが、ハンドヘルド限界のないデバイス上のクライアントのために最適化されています。考慮を必要とする要因には、限られたメモリ及び処理能力を含みます。限られた帯域幅も比較的高コストです。既に上記で触れたように、多くの場合（例えば、携帯機器）に、モバイル・クライアントは、マルチモーダルです。だから、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.
（3GPP、3GPP2、及びOMAによって定義されるような）無線MMSサービス[43]と同等またはより優れた機能を提供しない、明示的な目標、が望ましいです。
Proposed Wireless User Interface (WUI)/Multi-modal Clients
提案されたワイヤレスユーザーインターフェース（WUI）/マルチモーダルクライアント
|wireless GUI client| email server
|無線GUIクライアント|電子メールサーバー
(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
|----------------voice messaging system ----------------|
|------WUI-----| |---mail server---|
Wireless GUI client consists of: GUI (Graphical User Interface) and GUA (Graphical User Agent)
GUI（グラフィカルユーザインタフェース）とGUA（グラフィカル・ユーザー・エージェント）：ワイヤレスGUIクライアントの構成要素は
Communication between UI and UA is proprietary.
UIとUAの間の通信は独自のものです。
TUI client consists of: TUI (Telephone User Interface) and TUA (Telephone User Agent)
TUI（電話ユーザインターフェイス）とTUA（電話ユーザーエージェント）：TUIクライアントの構成要素は
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間の通信は独自のものです。
This is a list of principles to guide the design of extensions for Internet Messaging systems and protocols to support diverse endpoints.
これは、多様なエンドポイントをサポートするために、インターネットメッセージングシステムとプロトコル用の拡張機能の設計を導くための原則のリストです。
To the extent feasible, the enhanced messaging framework SHOULD use existing protocols whenever possible.
可能な限り、可能な範囲で、強化されたメッセージングフレームワークは、既存のプロトコルを使用すべきです。
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.
別の言い方をすると、私たちは、既存のプロトコルを中断されません。
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.
ユーザがメッセージを受信した場合、そのメッセージは、送信者が期待する治療を受けるべきです。送信者は、彼が音声メッセージを送信していると考えている場合たとえば、音声メッセージの意味は、受信側のクライアントは、このような治療をサポートできる程度に勝つ必要があります。
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.
ユーザーがメッセージを送信すると、彼はメッセージコンテキストを指定できるようにすべきです。これは、ネットワークが再びなど、テキストメッセージ、音声メッセージ、ビデオメッセージ、メッセージとして扱うべきかどうか、これが唯一のインフラと受信側のクライアントは、そのような治療を提供できる程度に遵守することができています。実際には、これは、メッセージが受信クライアントへの配信まで、送信者が希望する形でなければならないことを暗示します。
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.
新しい機能のために必要な場合には、インフラストラクチャのみ変更する必要があります。既存の機能は、既存のインフラストラクチャに保存されなければなりません。つまり、すべての拡張機能は、拡張機能の漸進的な導入を可能にするために、後方互換性がなければなりません。強化されたメッセージングのコンテキストで作成されたメッセージは、既存のメールクライアントへの変更を要求してはなりません。しかし、特定の状況で機能の低下があってもよいです。
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]テキストメッセージ。
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.
検索側では、音声の再生のためのメッセージを取得するための重要なリアルタイムの要件があります。ビデオを含む任意の他のメディアタイプより、音声再生待ち時間の変化に非常に敏感です。強化されたメッセージングフレームワークは、音声のリアルタイムのニーズに対応しなければなりません。
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.
このニーズに対処することはレモネードの範囲ではありません。
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つの顕著な特徴を持っている：ビデオメッセージは、潜在的に大きいです！強化されたメッセージングフレームワークは、非常に大きなメッセージのためにスケールしなければなりません。サーバからクライアントへのストリーミング、両方向に、サポートしなければなりません。
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を拡張するに自分自身を制限しなければなりませんし、新しいプロトコルを作成してはいけません。
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).
リアルタイム再生を実現するには、いくつかのアプローチがあります。第1のアプローチは、それがネットワークから受信されるアプリケーションに増分データを渡すことができる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などのストリーミングメディアプロトコルを介してクライアントへの音声データを利用できるようにサーバーを頼むことができます。これは一般的なストリーミングプロトコルのクライアントとサーバー上のサポートが必要です。
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」のようなテキストのような内容転送符号化ではなく、より効率的なネイティブコード化を使用してデータの転送を可能にしています。
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は、すべてのデータがテキストのように見える形で表現されたテキストベースのデータ表現方式を使用します。つまり、音声データは、メッセージのサイズに30％を加算輸送符号に「ベース64」を用いて符号化されなければなりません。サーバーへの大きなメッセージをダウンロードするか、追加することは、すでにかなりの帯域幅を使用しています。
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バイナリ拡張規格案[31] IMAPは、バイナリ形式のデータを取得するためのコマンドをフェッチ延びています。これは、大きな添付ファイルや他のバイナリコンポーネントのために特に便利です。ストリーミングクライアントの実装と併せてのバイナリは、チャネルの拡張に代わる魅力的な選択肢になります。
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.
共通TUIプロンプトは、「あなたは二つの新しい音声メッセージ、6つの前代未聞のメッセージ、および1つの新しいファックスメッセージを持っている」、便利な現在のメッセージ検索プロトコルによって使用可能になるよりも、より多くの情報が必要です。
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プロトコルのメールボックスstatusコマンドは、メッセージコンテキスト[26] [27]のカウントが含まれていません。メールサーバは、これらの現在のカウンタを追跡し、任意のメールボックスの要約を返すstatusコマンドを提供するための可能なソリューションです。 IMAP statusコマンドは、メッセージヘッダから抽出された標準化された属性を持つ新しいと合計メッセージの数を提供します。この所定の情報は、現在のメッセージのタイプに関する情報が含まれていません。 statusコマンドへの追加規則がなければ、クライアントはその型、遅延や帯域幅の制約が存在して法外な費用を決定するために、各メッセージのヘッダーをダウンロードする必要があります。
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.
この機能は、ボイスメールボックスは、一般的にそうであるように、単一の論理キュー内最初にして新しいファックスメッセージを新しい音声メッセージを提示する必要があります。繰り返しますが、これは利便性とパフォーマンスの問題があります。メールサーバは、コンテキストによってソートを提供したり、「メールボックスの概要サポート」、第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は、これを直接サポートしていません。簡単な解決策は、任意のヘッダの内容をソートするための拡張可能なソート機構を定義することです。
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.
拡張メールボックスのサポートを効率的状況現在ログイン以外のメールボックスをする能力が必要です。この機能は、共通の特徴は、同じ家族グループ内の他のサブメールボックスが新しいメッセージを持っているかどうかを確認することで、サブメールボックスをサポートするために必要です。
Current mechanisms are limited to logging into each of set of mailboxes, checking status, logging out, and repeating until all sub-mailboxes are processed.
現在のメカニズムは、メールボックスのセットのそれぞれへのログイン状態を確認し、ログアウト、およびすべてのサブメールボックスが処理されるまで繰り返すことに限定されています。
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).
こうしたチェック領収書、削除されたメッセージの回復、再保存、および他のような機能を提供するアプリケーションは、特定の動作（例えば、送信トレイ、送信済みアイテム、削除済みアイテム、期限切れアイテム、下書き）と所定のメールボックス内のメッセージにアクセスすることが必要です。
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は、単一の標準化されたフォルダ、受信トレイを提供します。この機能は、それ自体が新しいプロトコルの追加を必要としませんが、標準化された使用法と命名規則は、相互運用性のために必要です。この機能は、サーバーが自動挿入、予定のコピー、および定期的な削除を含むこれらの特別なフォルダを、サポートするための基本的なロジックを提供する必要があります。
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.
多くのコール機能は、収集、発信者ID情報に依存しています。クライアント - などTUIや他のサービスのユーザーエージェントをサポートする（例えば、WEBやWAPサーバ）として - コールバックなどの目的のために制限された発信者ID情報への信頼できるアクセスが必要な場合があります。信頼できないクライアントは、この情報の受信を許可してはいけません。適切なクライアントとサーバの間の「信頼」を確立するためのメカニズムは、許可された唯一のようエンドユーザーにこの情報の配信を制限するために必要とされます。
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.
さらに、メッセージは識別情報が不適切に受信者に公開されていないことを保証しながら、送信者の身元を記録管理及び特定の機能のために保存することができるように、信頼を伝達する手段が必要とされる、ネットワーク内のサーバ間で送信される場合仕方。
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]は、この多元接続技術をサポートするために必要な規則の候補セットを記述する。それか、他のいくつかの方法がレモネードの一部として標準化されなければなりません。
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.
一つのアプローチは、最終的な宛先にメッセージを中継する前に、メッセージ内に埋め込まれた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）のそれとの間の区別をmuddies。この場合には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]。
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つのタイプ（例えば、電子メールメッセージ）の倍数（大）メッセージの予防です。一つのタイプのすべてのクォータの消費は、メールボックスへの他のタイプ（例えば、音声またはファックスメッセージ）の配信を防止します。
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]プロトコルへの拡張によるものであってもよいです。
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への拡張は、将来のメッセージをキャンセルするなどの目的のために、送信キューを表示および操作するために必要とされています。それらが意図されているときにメッセージが送信されるように、このようなキューを管理するためのサーバーのサポートが必要です。
Some of the architectural issues here are the same as those in "Forward without Download Support" (Section 6.2.1).
ここでは、建築の問題のいくつかは、「ダウンロードサポートなしの転送」（6.2.1項）と同様です。
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つの制限があります。最初の、そして最も管理し、メッセージ転送が加入者によって許容されるよりも多くの時間がかかる可能性があることです。第二は、メッセージがメールボックスに配信することができない可能性があることです。呼び出し側に通知を返す方法はありませんので、メッセージが「失われた」です。
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.
標準化コミュニティは、SMTPの代わりに取り組んでいるローカルメッセージ転送プロトコル（LMTP [35]）と呼ばれます。メールボックスへの原子の送達を提供するために使用される場合、このプロトコルは、SMTPに多くの制限に対処します。メッセージごとのクォータ執行機関や指定管理者のメッセージのメッセージ記憶域のクォータ・オーバーライドの問題があるとして、この提案で故障モードは、慎重に、制御されています。
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を使用して上の歴史的な制限は、フルSMTPエンベロープを通信するためにIMAPのできないことを含みます。電話応答のために、これらの制限は重要ではありません。しかし、このアプローチが提起したアーキテクチャの問題は重要です。 （6.2.1項）、「フォワードダウンロードサポートなし」を参照してください。
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または各メッセージの到着イベント、メッセージの読み取りイベント用ポケットベル通知、メールボックスの完全なイベントを送信するのが一般的です
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.
標準化コミュニティは、バルクサーバからクライアントへのステータス通知のための標準に取り組んでいます。そのような作業の例は、様々なイベントのためのメッセージストアの予想される動作を定義する単純な通知、アラームプロトコル（SNAP）[45]、であり、それらの多くは、IMAPコマンドによってトリガ。
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).
「統一通知プロトコルの考慮事項」（付録C）：このための設計を考慮にIABのノートを取る必要があります。
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を「プッシュ」のいずれかによって中断されることが比較的高い可能性があります。
It is also common in these environments that the device's IP address change within a session.
これは、これらの環境のセッション内のデバイスのIPアドレスの変更にも一般的です。
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クライアントサイズのハンドセットに常駐するクライアントは、サイズが限られています。 Oランタイムメモリワイヤレスハンドセットは、モバイル電子メールクライアントを使用するためのランタイムメモリが限られています。 O CPU高速無線ハンドセットは、電子メールクライアントを実行する従来のシステム（PCS）のものより劣っているCPUを持っています。 Oユーザーインターフェイスの携帯電話は非常に限られた入力および出力機能を持っています。それらのほとんどは、唯一の初歩的なキーボード（キーパッド）と初歩的なポインティングデバイス（テキストカーソル）を持っています。
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.5Gおよび3Gネットワークは、これを改善します。しかし、既存の電子メールクライアントは、非常に大きなファイル（数MB単位まで）が必要 - などのプレゼンテーション、画像、音声、ビデオなどのマルチメディアの添付ファイルで遭遇 - モバイルが（ためのデータのほとんどを利用できない場合でもダウンロードします色深度と画面サイズの制限）。空気を介してこのような大きなファイルを転送する高い無線帯域幅が利用可能であっても疑わしい価値があります。
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 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.
多くの場合、モバイル・データ・サービスの利用者は、携帯電話にダウンロードされるデータの量（例えば、キロバイト）で充電されています。ほとんどのユーザーは、現在彼らは、ワイヤラインサービス上で行うよりも無線サービスと高あたりのキロバイトのデータ電荷を経験します。ユーザーは無線サービスのためのプレミアムに敏感です。不本意でのこの結果は、選択したコンテンツをダウンロードすることができるように携帯電話と欲望への不必要な大量のデータをダウンロードします。
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）の結果です。
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の電子メールクライアントが表示できるようになるのと同じ表示）で一回。そのため、モバイル宛ての多くの電子メールの添付ファイルが適切に表示されるためにサイズ、色深度、およびプレゼンテーション方法の変更が必要な場合があります。
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クライアントは、ドキュメントタイプの多種多様なサポート（オンデマンド「コーデック」/プレーヤーのダウンロードが可能）が、携帯電話は非常に限定的なサポートを持っています。 （例えば、最ものみサポートWAVオーディオや、AU、MP3やAIFFなどの他の形式を再生することはできません。）また、現在販売され、ほとんどすべての新しい携帯電話は、いくつかの高度なフォーマット、他のメディアを表示するための支援や用途向けに画像や音声を表示することができますが、そのようなMSオフィス（TM）などの特定の形式は、近い将来に広範であることが期待されていません。
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.
上述したように、そこに市場で入手可能な多くの携帯電話の種類があり、それぞれが異なる表示能力、画面特性、および処理能力を有しています。携帯メールサービスは、できるだけ多くのハンドセットタイプをサポートすることができるはずです。
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.
そのため、全体ではなく添付ファイルが、それをいうだけで選択した部分をダウンロードするには、ユーザーを有効にする必要があります。たとえば、ユーザーがドキュメントの「目次」をダウンロードすることができるはずです。文書内を検索します。プレゼンテーションの最初のスライドをダウンロードします。このプレゼンテーションの次のスライドまたはスライドの範囲など
The following requirements are derived from the considerations mentioned above.
次の要件は、上記の考察から派生しています。
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の接続は、メールセッション中に継続的にアップしたままに通信ソケットが必要です。コミュニケーションの過渡的損失の場合には、接続が再確立されなければなりません。これは、サーバーに再接続し、セッションに等価な状態に戻るには、クライアント次第です。接続を復元するこのオーバーヘッドは、応答時間と追加のデータ伝送に非常に高価です。
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.
携帯メールプロトコルは、それを取得せずにメッセージを転送する機能をサポートしなければなりません。
This requirement is identical to the TUI requirement described in "Forward Without Download Support" (Section 6.2.1).
この要件は、（6.2.1項）、「ダウンロードサポートなしで進む」で説明したTUI要件と同じです。
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).
この要件は、「リアルタイム再生」（セクション6.1.1.1）で説明したTUI要件に似ています。
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消費量0における効率的なサイズ0で
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サーバとの相互運用性を制限してはなりません。
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.
一つの方法は、受信ハンドセットの機能のためのメッセージを最適化するために、メッセージ検索の前に、サーバーによるコンテンツトランスコーディング、メディア適応の使用です。
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).
第三のアプローチは、（セクション6.1.1.2）「コンテンツ転送エンコードデータインフレを避ける」で説明したように、帯域幅の使用量を最小限にすることです。
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.
前述したように、ワイヤレスデバイスは、メディアを処理する能力が限られています。そのため、サーバーは有効データを表示するには、端末を有効にするには、情報操作のアクティビティを実行する必要がすることができます。
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]）の作業は、この問題に対処することができます。
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]）は、この問題に対処することができます。
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'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）と相互運用する方法の仕様を含んでいます。
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.
E.164アドレッシング[62]は、受信者の携帯電話に対処するモバイルメッセージングサービスで流行しています。検討アドレッシングRFC822に加えて、モバイルデバイスのためのE.164アドレッシングをサポートに与えられるべきです。
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のものに匹敵する携帯電話のためのサポートのレベルが望まれる場合、この動作モードを考慮しなければなりません。
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節）でに言及されました。ほとんどの既存の無線メールシステムが不要なポーリングを避けるために、通知を使用するものの、インターネットメールは、これまでのところ、サーバーからクライアントへの通知プロトコルを標準化していません。クライアントからサーバーへの通知は、レモネード憲章の範囲内ではありません。
Support for committed delivery is described in Section 6.2.4, but this is different.
コミット配信のためのサポートは、6.2.4項に記載されているが、これは異なっています。
If a push model of message retrieval is supported, the need for selective downloading and SPAM control is especially important.
メッセージ検索のプッシュモデルがサポートされている場合は、選択的なダウンロードとSPAM制御の必要性は特に重要です。
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 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の範囲外、具体的であることに留意されたいです。
Some mobile networks require network authentication as well as application authentication.
一部のモバイルネットワークでは、ネットワーク認証だけでなく、アプリケーションの認証を必要とします。
The 3GPP MMS Reference Architecture ([48] [54]) defines seven interfaces labelled MM1 to MM7, as below:
3GPP MMS参照アーキテクチャ（[48] [54]）は、以下のように、MM7にMM1標識7つのインターフェースを定義しています。
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 - Multimedia Messaging Service
UMS - Unified Messaging Service
HLR - Home Location Register
DB - Data Base
VAS - Value Added Service
APP - Application
The LEMONADE profile provides an enhanced IMAP mail retrieval protocol suitable for use at interfaces MM1 and MM3.
レモネードプロフィールは、インタフェース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.
無線デバイスは、レモネード強化IMAPユーザエージェントを使用する場合に加えて、拡張IMAPプロトコルは以下のように、直接インターネットメールにアクセスするために使用することができます。
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 ->| |
|-------| |------------|
MMS - Multimedia Messaging Service
UMS - Unified Messaging Service
HLR - Home Location Register
DB - Data Base
VAS - Value Added Service
APP - Application
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.
セキュリティが強化されたメッセージングの非常に重要な部分になります。目標は、可能な限り、既存のメッセージングシステムのセマンティクスを保護し、セキュリティと信頼性に対するユーザーの（既存の）期待に応えることです。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[2] Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August 1982.
[2]クロッカー、D.、 "ARPAインターネットテキストメッセージの形式の規格"、STD 11、RFC 822、1982年8月。
[3] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", RFC 3461, January 2003.
[3]ムーア、K.、 "配信状態通知のための簡易メール転送プロトコル（SMTP）サービス拡張（DSNの）"、RFC 3461、2003年1月。
[4] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996.
[4]マイヤーズ、J.とM.ローズ、 "ポストオフィスプロトコル - バージョン3"、STD 53、RFC 1939、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）第一部：インターネットメッセージ本体のフォーマット"、RFC 2045、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：メディアタイプ"、RFC 2046、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.、 "MIME（多目的インターネットメール拡張）パート3：非ASCIIテキストのためのメッセージヘッダの拡張"、RFC 2047、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：登録手順"、BCP 13、RFC 2048、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：適合基準と例"、RFC 2049、1996年11月。
[10] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[10]クリスピン、M.、 "インターネットメッセージアクセスプロトコル - バージョン4rev1"、RFC 3501、2003年3月。
[11] Myers, J., "IMAP4 QUOTA extension", RFC 2087, January 1997.
[11]マイヤーズ、J.、 "IMAP4クォータ拡張"、RFC 2087、1997年1月。
[12] Hansen, T. and G. Vaudreuil, "Message Disposition Notification", RFC 3798, May 2004.
[12]ハンセン、T.およびG.ボードルイ、 "メッセージ気質通知"、RFC 3798、2004年5月。
[13] Vaudreuil, G. and G. Parsons, "Voice Profile for Internet Mail - version 2 (VPIMv2)", RFC 3801, June 2004.
[13]ヴォードルイユ、G.とG.パーソンズ、 "インターネットメール用の音声プロファイル - バージョン2（VPIMv2）"、RFC 3801、2004年6月。
[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.パーソンズ、 "トール品質の音声 - 32キロビット/秒適応差分パルス符号変調（ADPCM）MIMEサブタイプ登録"、RFC 3802、2004年6月。
[15] Vaudreuil, G. and G. Parsons, "Content Duration MIME Header Definition", RFC 3803, June 2004.
[15]ヴォードルイユ、G.とG.パーソンズ、 "満足している持続時間MIMEヘッダー定義"、RFC 3803、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.、VENABLE、D.、マッキンタイア、L.、パーソンズ、G.、およびJ.・ラファティ、 "インターネットファクスのファイル形式"、RFC 3949、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.・ラファティ、 "タグイメージファイル形式（TIFF） - 画像/ TIFFのMIMEサブタイプ登録"、RFC 3302、2002年9月。
[18] Allocchio, C., "Minimal GSTN address format in Internet Mail", RFC 3191, October 2001.
[18] Allocchio、C.、 "インターネットメールにおける最小GSTNアドレス形式"、RFC 3191、2001年10月。
[19] Allocchio, C., "Minimal FAX address format in Internet Mail", RFC 3192, October 2001.
[19] Allocchio、C.、 "インターネットメールにおける最小のFAXアドレス形式"、RFC 3192、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.翼、 "インターネットメールを使用するファクシミリのシンプルモード"、RFC 3965、2004年12月。
[21] Parsons, G. and J. Rafferty, "Tag Image File Format (TIFF) - F Profile for Facsimile", RFC 2306, March 1998.
[21]パーソンズ、G.とJ.・ラファティ、 "タグイメージファイル形式（TIFF） - ファクシミリのためのFプロフィール"、RFC 2306、1998年3月。
[22] Gellens, R. and J. Klensin, "Message Submission", RFC 2476, December 1998.
[22] Gellens、R.及びJ. Klensin、 "メッセージ送信"、RFC 2476、1998年12月。
[23] Masinter, L. and D. Wing, " Extended Facsimile Using Internet Mail", RFC 2532, March 1999.
[23] Masinter、L.とD.ウィング、 "インターネットメールを使用して、拡張ファクシミリ"、RFC 2532、1999年3月。
[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.、ゲティス、J.、モーグル、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - HTTP / 1.1" 、RFC 2616、1999年6月。
[25] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[25] Klensin、J.、 "簡易メール転送プロトコル"、RFC 2821、2001年4月。
[26] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[26]レズニック、P.、 "インターネットメッセージ形式"、RFC 2822、2001年4月。
[27] Burger, E., Candell, E., Eliot, C., and G. Klyne, "Message Context for Internet Mail", RFC 3458, January 2003.
[27]バーガー、E.、Candell、E.、エリオット、C.、およびG. Klyne、 "インターネットメールのためのメッセージコンテキスト"、RFC 3458、2003年1月。
[28] Burger, E., "Critical Content Multi-purpose Internet Mail Extensions (MIME) Parameter", RFC 3459, January 2003.
[28]バーガー、E.、 "重要なコンテンツ多目的インターネットメール拡張（MIME）パラメータ"、RFC 3459、2003年1月。
[29] Gahrns, M., "IMAP4 Multi-Accessed Mailbox Practice", RFC 2180, July 1997.
[29] Gahrns、M.、 "IMAP4マルチアクセスされるメールボックスの実践"、RFC 2180、1997年7月。
[30] Candell, E., "High-Level Requirements for Internet Voice Mail", RFC 3773, June 2004.
[30] Candell、E.、 "インターネットボイスメールのための高レベルの要件"、RFC 3773、2004年6月。
[31] Nerenberg, L., "IMAP4 Binary Content Extension", RFC 3516, April 2003.
[31] Nerenberg、L.、 "IMAP4バイナリコンテンツ拡張"、RFC 3516、2003年4月。
[32] Nerenberg, "IMAP4 Channel Transport Mechanism", Work in Progress, November 2001.
[32] Nerenberg、 "IMAP4チャンネル搬送機構"、進歩、2001年11月の作品。
[33] Toyoda, K. and D. Crocker, "SMTP Service Extensions for Fax Content Negotiation", Work in Progress, February 2003.
[33]豊田、K.、およびD.クロッカー、「ファックスコンテントネゴシエーションのためのSMTPサービス拡張」、進歩、2003年2月に作業。
[34] McRae, S. and G. Parsons, "Internet Voice Messaging (IVM)", RFC 4239, November 2005.
[34]マクレー、S.およびG.パーソンズ、 "インターネットボイスメッセージ（IVM）"、RFC 4239、2005年11月。
[35] Murchison, K. and L. Greenfield, "LMTP Service Extension for Ignoring Recipient Quotas", Work in Progress, June 2002.
[35]マーチソン、K.とL.グリーンフィールド、「受信者クォータを無視するためのLMTPサービス拡張」、進歩、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] Gellens、R.、 "IMAPメッセージ提出"、進歩、2003年12月の作業。
[39] Resnick, P., "Internet Message Access Protocol (IMAP) CATENATE Extension", Work in Progress, December 2003.
[39]レズニック、P.、 "インターネットメッセージアクセスプロトコル（IMAP）CATENATE拡張"、進歩、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.、 "メッセージ提出BURL拡張"、進歩、2004年7月の作業。
[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]レウカ、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.、RFC 3842、2004年8月「セッション開始プロトコル（SIP）のためのメッセージサマリとメッセージ待機表示イベントパッケージ」。
[45] Shapira, N. and E. Aloni, "Simple Notification and Alarm Protocol (SNAP)", Work in Progress, December 2001.
[45] Shapira、N.とE.アロニ、 "シンプルな通知とアラームプロトコル（SNAP）"、進歩、2001年12月の作業。
[46] Vaudreuil, G., "Messaging profile for telephone-based Messaging clients", Work in Progress, February 2002.
[46]ヴォードルイユ、G.、「電話ベースのメッセージングクライアント用のメッセージングプロファイル」、進歩、2002年2月での作業。
[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"、オープン・モバイル・アライアンス（OMA）OMA-WAP-MMS-ARCH-v1_1- 20021101-C、2002年11月。
[49] OMA, "Push Architectural Overview", Open Mobile Alliance (OMA) WAP-250-PushArchOverview-20010703-a, July 2001.
[49] OMAは、 "アーキテクチャの概要を押してください"、オープン・モバイル・アライアンス（OMA）WAP-250-PushArchOverview-20010703-、2001年7月。
[50] OMA, "Push Access Protocol Specification", Open Mobile Alliance (OMA) WAP-247-PAP-20010429-a, April 2001.
[50] OMAは、 "アクセスプロトコル仕様を押してください"、オープン・モバイル・アライアンス（OMA）WAP-247-PAP-20010429-、2001年4月。
[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）OMA-WAP-MMS-CTR-v1_1-20021031-C、2002年10月。
[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- 20021030-C、2002年10月。
[54] OMA, "User Agent Profile, Version 1.1", Open Mobile Alliance (OMA) OMA-UAProf-v1_1-20021212-C, December 2002.
[54] OMA、 "ユーザエージェントプロファイル、バージョン1.1"、オープン・モバイル・アライアンス（OMA）OMA-のUAProf-v1_1-20021212-C、2002年12月。
[55] OMA, "Email Notification Version 1.0", Open Mobile Alliance (OMA) OMA-EMN-v1_0-20021031-C, October 2002.
[55] OMA、 "電子メール通知バージョン1.0"、オープン・モバイル・アライアンス（OMA）OMA-EMN-v1_0-20021031-C、2002年10月。
[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 TS 22.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 TS 23.140、2001。
[58] 3GPP2, "Short Message Service (SMS)", 3GPP2 TSG C.S0015-0, December 1999.
[58] 3GPP2、 "ショートメッセージサービス（SMS）"、3GPP2 TSG C.S0015-0、1999年12月。
[59] 3GPP2, "Enhanced Message Service (EMS) Stage 1 Description", 3GPP2 TSG S.R0051-0 v1.0, July 2001.
[59] 3GPP2、 "拡張メッセージサービス（EMS）ステージ1つの説明"、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：信号システム第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：シグナリングシステム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勧告シリーズE、1997年5月。
[63] ITU, "Specifications of Signalling System Number 7", ITU White Book, ITU-T Recommendation Q.763.
、ITUホワイトブック、ITU-T勧告Q.763 [63] ITU、 "シグナリングシステムナンバー7の仕様"。
[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、「端末がパケット・モードで動作し、専用回路によって公衆データネットワークに接続するためのデータ端末装置（DTE）とデータ回線終端装置（DCE）との間のインタフェース」、ITU-T勧告X.25 10月1996。
[65] BELLCORE, "Specifications of Signalling System Number 7", GR-246-CORE Issue 1, December 1994.
、GR-246-COREの1号、1994年12月[65] BELLCORE、 "シグナリングシステム番号7の仕様"。
Appendix A. Contributors
付録A.協力者
Eric Burger Brooktrout Technology, Inc. 18 Keewaydin Dr. Salem, MA 03079 USA
エリックバーガーブルックトラウト・テクノロジー社18 Keewaydin博士セーラム、MA 03079 USA
Phone: +1 603 890-7587 EMail: eburger@brooktrout.com
電話：+1 603 890-7587 Eメール：eburger@brooktrout.com
Yair Grosu Comverse 29 Habarzel St. Tel-Aviv 69710 Israel
Yair Grosuコンバース29 Habarzelセントテルアビブ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
グレン・パーソンズNortel Networksの私書箱K1Y 4H7カナダONボックス3511駅のCオタワ、
Phone: +1 613 763-7582 EMail: gparsons@nortelnetworks.com
電話：+1 613 763-7582 Eメール：gparsons@nortelnetworks.com
Milt Roselinsky Openwave Systems, Inc. 530 E. Montecito St. Santa Barbara, CA 93103 USA
ミルトRoselinskyオープンウェーブ・システムズ・インク530 E.モンテシトセントサンタバーバラ、CA 93103 USA
Phone: +1 805 884-6207 EMail: milt.roselinsky@openwave.com
電話：+1 805 884-6207 Eメール：milt.roselinsky@openwave.com
Dan Shoshani Comverse 29 Habarzel St. Tel-Aviv 69710 Israel
ダンShoshaniコンバース29 Habarzelセントテルアビブ69710イスラエル
EMail: Dan.Shoshani@comverse.com
メールアドレス：Dan.Shoshani@comverse.com
Alan K. Stebbens Openwave Systems, Inc. 530 E. Montecito St. Santa Barbara, CA 93103 USA
アラン・K. Stebbensオープンウェーブ・システムズ・インク530 E.モンテシトセントサンタバーバラ、CA 93103 USA
Phone: +1 805 884-3162 EMail: alan.stebbens@openwave.com
電話：+1 805 884-3162 Eメール：alan.stebbens@openwave.com
Gregory M. Vaudreuil Lucent Technologies 7291 Williamson Rd. Dallas, TX 75214 USA
グレゴリーM.ヴォードルイユルーセント・テクノロジーズ7291ウィリアムソンRdを。ダラス、TX 75214 USA
Phone: +1 214 823-9325 EMail: GregV@ieee.org
電話：+1 214 823-9325 Eメール：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.
アリEREVと（コンバースからの両方）ノーム・Shapiraは電話ベース（TUI）メッセージングクライアントをサポートするために、IMAPのための実質的な要件に貢献しました。メイアMendelovich（コンバース）は、無線要件のセクションをマージして助けました。ベンジャミン・エルズワース（オープンウェーブ）は、モバイルメッセージングアーキテクチャと要件に貢献しました。 Yaacov（ジェリー）ヴェンガルテン（コンバース）とステファン・マース（オラクル）は、最終的な文書に詳細なコメントを提供しました。
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の要求に応じて処方しました。以下の材料は、参照として使用した：*ドラフト-dusseault-S2S - イベント - REQS-00.txt（通知要件）* IETF 56からレモネードWGのための会議メモ*ドラフトshapira-スナップ05.txt（プロトコル設計インターネット全体の通知1998年UCIワークショップからジェネリック通知プロトコルのいくつかの側面を持っているSNAP）* LEMONADE WGチャーター*レモネードリストの最近の電子メールのための*いくつかの発表
* The Web pages for KnowHow, a company founded by Rohit Khare which has a proprietary Internet-wide notification system.
*ノウハウ、独自のインターネット規模の通知システムを持っていロフィット・クヘアによって設立された会社のWebページ。
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.
材料を見直し、Windows上またはToolTalkのようなOLAY / COMは、Solaris上だったように、デスクトップアプリケーション統合メカニズムの求められますと機能の同じ種類のジェネリック通知プロトコルから求められているように思われたが、メッセージングのレベルで後インターネットを介し。欲望は、異なるアプリケーション固有のメカニズムを有する種々の分散アプリケーションは、各アプリケーションがそれぞれ他のアプリケーションと相互作用を有するのN×N個の問題を有することなく相互運用することができなければならないということです。 IETF 56からレモネードにリサDusseaultによるプレゼンテーションであるcannonical例は、SMSのように、一度に使用するXMPPインスタントメッセージングのような、一つのアプリケーションからの通知を送信し、それは受信者が起こったどんなデバイスに配信有しています携帯電話に。
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.
デスクトップ上のアプリケーションの積分するメカニズムと通常の問題は、様々なアプリケーションが実際にメカニズムを使用して取得する方法です。ほとんどのアプリケーション開発者は、主要な付加価値の自分のアプリケーションでは、Microsoft Officeとうまくプレーできることを参照するのでWindowsの場合、これは、比較的容易です。 ToolTalkのために、残念ながら、Solarisの開発者は、10倍の改善を見ていない、そしてそれは、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 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.
あなたはドラフトshapiraスナップ-05.txtに図1を見れば、その答えは、通知クライアントは、機能エンティティに、この場合には受信クライアント上で（サーバー？モジュールを汎用プロトコル、SNAPを使用していることのようですか？ ）は、アプリケーション固有の通知に、一般的な通知を処理し、クライアントにその通知を送信する「通知サービス」と呼ばれます。この図から、通知クライアントが変更を必要とするだろうが、受信したクライアントがないかのように見えます。
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.
ジェネリック通知プロトコルの文脈では、これはいくつかの潜在的な問題を提起します。一つは、ドラフトdusseault-S2S - イベント - REQS-00.txtを識別され、アドレッシングされていますが、ある意味で、これは既存のと、おそらく、新たに定義されたURIを使用することによって、解決するのが最も簡単です。より複雑な問題は、前提条件が異なるアプリケーション通知メカニズムを横断イベントのトリガを構成するものの意味と一致しています。これは、しかし、それはまた、サブスクリプションは、一般的な通知メカニズムを使用してイベントをフィルタリングするために行うことができるサブスクリプションサービスのために必要とされる以上という問題サブスクリプションをすることができ、もちろん異なるイベント通知メカニズムと、一般的な機構との間の通知を変換する必要があります異なるアプリケーション固有のメカニズムに翻訳。一般的なサブスクリプションを表現するための任意の言語が異なるアプリケーション通知のセマンティクスに細かい点を表現するサポートすることはほとんどありません。 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.
レモネードリストw.r.t.に今年初めに議論された別の建築の問題、他のいくつかのトピックは、ゲートウェイ処理されます。それはPSTNベースのメカニズム（SMS）にIPベースのメッセージング・メカニズム（XMPP）の間の変換を必要とするので（XMPPを使用して携帯電話にSMSを介して到着する送信されたメッセージ）上記cannonical例では、実際にゲートウェイ例です。この目的のために統一された通知メカニズムを使用しての問題点は、両者の間の一般的な他の機能がある場合、ゲートウェイはとにかく建設される可能性があるということです。実際には、レモネードのための作業項目の一つは、このようなゲートウェイを調査することです。一般的な通知メカニズムの値は、従って、この光で評価する必要があります。
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が統一やバイに強いベンダーやサービスプロバイダーがない限り、既存の独自のメカニズムに取って代わる仕組みを導入する際に特定の成功を受けていないということです。二つの例は、インスタントメッセージングおよびサービスの発見です。インスタントメッセージングでは、標準化さ、統一インスタントメッセージングプロトコルは、大手サービスプロバイダからのコミットメントの欠如によって遅延されたようです。サービスの発見では、ベンダーからの微弱なコミットメントは、IETF標準が整備されている後でさえも、ベンダー固有のサービス発見ソリューションの継続的な導入をもたらしました。 （著者が最もよく知られた）サービス・ディスカバリの状況は、標準化プロセスの最終段階での主要なベンダーのコミットメントの欠如に起因します。設計プロセスの終結の時までボードとコミットに独自の通知プロトコルとの重要なプレーヤーを持つ、一般的な通知プロトコルにこれらのlessionsを適用することは非常に重要になります。一般的なメカニズムが成功することができる前に主要なコミットメントは、様々なアプリケーションの通知プロトコルから必要とされています。任意のIETF標準化作業に必要な時間と労力を考えると、客観目でこれらを評価することは重要である、そうでない場合は、関係なく、うまくプロトコルを設計したか、技術的の展開の成功が不足することができる、です。誰も配備しないelegently設計ソリューションを持つことは避けるのが賢明かもしれない結果です。
James Kempf July 2003
ジェームズ・ケンプ2003年7月
Author's Address
著者のアドレス
Jin Kue Wong (Editor) Nortel Networks P.O. Box 3511 Station C Ottawa, ON K1Y 4H7 Canada
ジンKUEウォン（編集）ノーテルネットワークP。 K1Y 4H7カナダONボックス3511駅のCオタワ、
Phone: +1 613 763-2515 EMail: j.k.wong@sympatico.ca
電話：+1 613 763-2515 Eメール：j.k.wong@sympatico.ca
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（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.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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は、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
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リポジトリから。
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エディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。