[要約] RFC 4416は、インターネットメッセージングが多様なサービス環境をサポートするための目標を示しています。このRFCの目的は、異なるサービス環境でのメッセージングの要件を明確にし、相互運用性を向上させることです。
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).
Copyright（c）The Internet Society（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.
レモネードワーキンググループ - 多様なサービス環境をサポートするためのインターネットメール - は、より多様なクライアントによる使用を促進するためにインターネットメールの強化を提供するためにチャーターされています。特に、ホストのクライアントは、高レイテンシ/帯域幅が制限された信頼できないリンクを持つ環境で動作するだけでなく、限られたリソースに制約されています。拡張されたメールは、既存のインターネットメールと逆方向に互換性がなければなりません。
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]は、輸送用のSS7コールコントロールインフラストラクチャ（[60]、[61]、[64]、[65]）を使用して、携帯電話間で携帯電話間で短いテキストメッセージを送信できるようになりました。。
In the recent past, IETF mail standards have evolved to support additional/merged functionality:
最近では、IETFメール標準が進化し、追加/マージされた機能をサポートしています。
o With MIME ([5], [6], [7], [8], [9], [28]), Internet mail transport was enhanced to carry any kind of digital data o Internet mail protocols were extended and profiled by VPIM ([13], [14], [15], [34]) and iFAX ([16], [17], [18], [19], [20], [21], [23]) so that enabled voice mail systems and fax machines could use the common email infrastructure to carry their messages over the Internet as an alternative to the telephone network. These enhancements were such that the user's experience of reliability, security, and responsiveness was not diminished by transport over the Internet.
o mime（[5]、[6]、[7]、[8]、[9]、[28]）を使用すると、あらゆる種類のデジタルデータを運ぶためにインターネットメールトランスポートが強化されました。（[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.
多様なサービス環境をサポートするためのインターネットメール - モバイルデバイスのインターネットメールサポートを可能にし、既存のモバイルメッセージングユニバースとの相互運用性を促進することにより、このビジョンをさらに実現します。
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プロトコルは、一部はインターネット標準（メッセージングとWeb [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）、これはポットセットによって提供されるユーザーモード *これは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多様なサービス環境向けのインターネットメッセージングの設計を導くために使用される原則のリスト。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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、RFC2119 [1]に記載されているように解釈される。
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.
2つの基本的なトランザクションモデルがあります。「プル」モデルでは、データフローではなくコンポーネントがトランザクションを開始します。たとえば、クライアントはサーバーへの接続を開始し、サーバーにリクエストを発行して着信メッセージを配信する場合があります。従来の電子メールクライアント、Webメールクライアント、WAPベースのモバイルクライアントは、「プル」モデルを使用しています。
The "push" model differs in that the component initiating the transaction does so because of some data flow affecting it. For example, the arrival of a new message at the terminating server may cause a notification to be sent ("pushed") to a messaging client.
「プッシュ」モデルは、トランザクションを開始するコンポーネントがそれに影響するデータフローのためにそうするという点で異なります。たとえば、終了サーバーに新しいメッセージが到着すると、メッセージがメッセージングクライアントに送信される（「プッシュ」）が送信される場合があります。
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 Notification and Delivery Status Message ([12], [3]). Voice media has also been added to multi-part message bodies.
これらのプロファイル、RFC3801 [13]からRFC3803 [15]は、インターネットメールシステムを使用して音声メッセージの輸送を可能にします。この作業の主なドライバーは、ボイスメールシステムのIP Transportのサポートでした。ボイスメールのクライアントは、メッセージ配信に関してより高い応答性と確実性に慣れているため、VPIMV2によって追加される機能にはメッセージ処分通知と配信ステータスメッセージが含まれます（[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]）により、インターネットメールプロトコルを使用してFAXの輸送が可能になります。この作業では、画像/TIFF MIMEタイプを定義しました。FAXクライアントのサポートには、メッセージ配信通知に拡張機能も必要でした。
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 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.
マルチモーダルクライアントは、ユーザーインタラクションの調整された音声モードとデータモードの利点を提供します。アーキテクチャには、マルチモーダルクライアントは、2つのユーザーエージェントコンポーネントのユニオンと見なすことができます。1つはTUIクライアント、もう1つは単純なGUIクライアントです。次の図を参照してください。グラフィカルユーザーエージェント（GUA）は、TOI機能に代わって電話ユーザーエージェント（TUA）が動作する一方で、テキストディスプレイの維持に役立ちます。
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.
ワイヤレスユーザーインターフェイスは、個人ワークステーション上の従来の電子メールクライアントと機能的に同等ですが、ハンドヘルドテザーレスデバイスのクライアント向けに最適化されています。考慮が必要な要因には、限られたメモリと処理能力が含まれます。限られた帯域幅も比較的高いコストです。すでに上記で言及されているように、多くの場合（たとえば、セルラーデバイス）、モバイルクライアントはマルチモーダルです。したがって、WUIはリソースとリンク制限のマルチモーダルクライアントとしてモデル化できます。
These terminals require the use of protocols that minimize the number of over-the-air transactions and reduce the amount of data that need be transmitted over the air overall. Such reduction in over-the-air transmission is a combination of more efficient protocol interaction and richer message presentation choices, whereby a user may more intelligently select what should be downloaded and what should remain on the server.
これらの端子には、航空のトランザクションの数を最小限に抑え、空気全体に送信する必要があるデータの量を減らすプロトコルの使用が必要です。このような空気伝送の減少は、より効率的なプロトコル相互作用とより豊富なメッセージプレゼンテーションの選択の組み合わせであり、ユーザーはダウンロードするものとサーバーに残るものをよりインテリジェントに選択できます。
Although not an explicit goal, providing equivalent or superior functionality to the wireless MMS service [43] (as defined by 3GPP, 3GPP2, and the OMA) is desirable.
明示的な目標ではありませんが、ワイヤレスMMSサービス[43]（3GPP、3GPP2、およびOMAで定義）に同等または優れた機能を提供することが望ましいです。
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クライアントは、GUI（グラフィカルユーザーインターフェイス）とGUA（グラフィカルユーザーエージェント）で構成されています
Communication between UI and UA is proprietary.
UIとUA間のコミュニケーションは独自のものです。
TUI client consists of: TUI (Telephone User Interface) and TUA (Telephone User Agent)
TUIクライアントは、TUI（電話ユーザーインターフェイス）とTUA（電話ユーザーエージェント）で構成されています
Communication between TUI and TUA is proprietary. Communication between GUA and TUA is proprietary.
TUIとTUAの間のコミュニケーションは独自のものです。GUAとTUAの間のコミュニケーションは独自のものです。
Mail (email and voice mail) server consists of: MS (Mail Store) and MTA (Message Transfer Agent)
メール（電子メールおよびボイスメール）サーバーは、MS（メールストア）とMTA（メッセージ転送エージェント）で構成されています
Communication between MS and MTA is proprietary.
MSとMTAの間のコミュニケーションは独自のものです。
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.
FAXユーザーは、インターネットメッセージングの強化にとって課題である特定の期待を持っています。FAXを送信する人は、受信者が送信成功したときにFAXを受け取ることを期待しています。これは明らかにインターネットメールの場合ではありません。
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).
リアルタイムの再生を実現するには、いくつかのアプローチがあります。最初のアプローチは、ネットワークから受信されたときにアプリケーションにデータを徐々に渡すことができる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".
もう1つの重要なパフォーマンスの最適化は、「ベース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.
Standard IMAP4は、すべてのデータがテキストのように見える形式で表現されるテキストベースのデータ表現スキームを使用します。つまり、音声データは、「ベース64」を使用して、メッセージのサイズに30％を追加するトランスポートエンコードにエンコードする必要があります。サーバーに大きなメッセージをダウンロードまたは追加すると、既にかなりの帯域幅が使用されています。
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 Fetchコマンドを拡張して、バイナリ形式のデータを取得します。これは、特に大きなアタッチメントやその他のバイナリコンポーネントに役立ちます。ストリーミングクライアントの実装と組み合わせたバイナリは、チャネル拡張に代わる魅力的な代替品かもしれません。
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プロンプト「2つの新しい音声メッセージがあり、6つの前代未聞のメッセージがあり、1つの新しいFaxメッセージがあります」には、現在のメッセージ検索プロトコルで便利に利用できるよりも多くの情報が必要です。
The existing IMAP protocol's mailbox status command does not include a count by message context [26] [27]. A possible solution is for the mail server to keep track of these current counters and provide a status command that returns an arbitrary mailbox summary. The IMAP status command provides a count of new and total messages with standardized attributes extracted from the message headers. This predetermined information does not currently include information about the message type. Without additional conventions to the status command, a client would have to download the header for each message to determine its type, a prohibitive cost where latency or bandwidth constraints exist.
既存のIMAPプロトコルのメールボックスステータスコマンドには、メッセージコンテキスト[26] [27]によるカウントは含まれません。可能なソリューションは、メールサーバーがこれらの現在のカウンターを追跡し、任意のメールボックスの概要を返すステータスコマンドを提供することです。IMAPステータスコマンドは、メッセージヘッダーから抽出された標準化された属性を備えた新しい合計メッセージのカウントを提供します。この所定の情報には、現在、メッセージタイプに関する情報は含まれていません。ステータスコマンドへの追加の慣習がなければ、クライアントは各メッセージのヘッダーをダウンロードして、そのタイプを決定する必要があります。これは、遅延または帯域幅の制約が存在する場合の法外なコストです。
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).
領収書のチェック、削除されたメッセージの回復、resaveなどの機能を提供するアプリケーションでは、特定の動作（例：アウトボックス、送信されたアイテム、削除されたアイテム、期限切れのアイテム、ドラフト）を備えた事前に決められたメールボックス内のメッセージにアクセスする機能が必要です。
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は、単一の標準化されたフォルダー、Inboxのみを提供します。この機能には、それ自体が新しいプロトコルの追加を必要としませんが、相互運用性には標準化された使用法と命名規則が必要です。この機能では、サーバーが自動挿入、スケジュールされたコピー、定期的な削除など、これらの特別なフォルダーをサポートするために、基礎となるロジックを提供する必要があります。
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サーバーなど）などのクライアントは、コールバックなどの目的で制限されたCaller-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クライアントからの同時ログインセッションとビジュアルクライアントからのアプリケーションが必要になる場合があります。
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.
1つのアプローチは、メッセージを最終目的地に中継する前に、メッセージ内の埋め込みURLをメッセージ内に解決するように送信サーバーに要求するメッセージへの拡張機能を定義することです。メッセージ送信サーバーはIMAPサーバーからデータをプルする必要があるため、このアプローチはプルアプローチと呼ばれます。
Another approach is to add a limited message assembly and submission capability to the IMAP server. This approach muddies the distinction between the message submission protocol and that for message storage and retrieval (IMAP) because now message submission may be a side effect of message store commands. This approach is referred to as the push approach because in this case the IMAP server pushes data to the message submission server.
別のアプローチは、IMAPサーバーに限られたメッセージアセンブリと送信機能を追加することです。このアプローチは、メッセージの送信プロトコルとメッセージの保存と取得（IMAP）の区別を泥だらけにします。これは、メッセージの送信がメッセージストアコマンドの副作用になる可能性があるためです。この場合、このアプローチはプッシュアプローチと呼ばれます。この場合、IMAPサーバーはデータ提出サーバーにデータをプッシュするためです。
A detailed analysis of which of the two approaches is preferable as well as implementation details of both can be found in references [36], [37], [38], [39], [40], and [41].
2つのアプローチのどれが好ましいかの詳細な分析と両方の実装の詳細は、参考文献[36]、[37]、[38]、[39]、[40]、および[41]に記載されています。
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]を提供することが一般的です。電子メールの洪水がメールボックスを満たし、サブスクライバーが電話で音声メッセージを受信するのを防ぐ条件を回避します。提出されたメッセージのコンテキストに基づいて、「Mailbox Full」ステータスのレポートをサポートするために、プロトコルを拡張する必要があります。
An obvious security issue needing consideration is the prevention of the deliberate misidentification of a message context with the intention of overflowing a subscriber's mailbox. It is envisioned that the message submission protocol will require the authentication of trusted submission agents allowing only those so authorized to submit distinguished messages.
検討を必要とする明らかなセキュリティの問題は、サブスクライバーのメールボックスにオーバーフローする意図を持つメッセージコンテキストの意図的な誤認の防止です。メッセージ送信プロトコルには、著名なメッセージを提出することが許可されたもののみが許可されている信頼できる提出エージェントの認証が必要になることが想定されています。
Voice mail system mailboxes commonly contain voice and fax messages. Sometimes, such systems also support email messages (text, text with attachments, and multimedia messages) in addition to voice messages. Similar to the required sort by message context, quota management is also required per message context.
ボイスメールシステムのメールボックスには、通常、音声メッセージとファックスメッセージが含まれています。時々、そのようなシステムは、音声メッセージに加えて、電子メールメッセージ（テキスト、添付ファイル付きのテキスト、マルチメディアメッセージ）もサポートしています。メッセージコンテキストによる必要なソートと同様に、メッセージコンテキストごとにクォータ管理も必要です。
One possible use case is the prevention of multiple (large) messages of one type (e.g., email messages) from consuming all available quota. Consumption of all quota by one type prevents the delivery of other types (e.g., voice or fax messages) to the mailbox.
考えられるユースケースの1つは、利用可能なすべてのクォータを消費する1つのタイプ（たとえば、電子メールメッセージ）の複数の（大）メッセージの防止です。1つのタイプですべてのクォータを消費すると、他のタイプ（音声メッセージやファックスメッセージなど）がメールボックスに配信されます。
One possible approach is to define a mechanism whereby a trusted client can declare the context of a message for the purpose of utilizing a protected quota. This may be by extensions to the SMTP-submit or LMTP[35] protocols.
考えられるアプローチの1つは、信頼できるクライアントが保護されたクォータを使用する目的でメッセージのコンテキストを宣言できるメカニズムを定義することです。これは、SMTP-Submitまたは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つの制限があります。最初で最も管理しやすいのは、メッセージの転送がサブスクライバーが許容できるよりも時間がかかる場合があることです。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.
標準コミュニティは、ローカルメッセージトランスポートプロトコル（LMTP [35]）と呼ばれるSMTPの代替案に取り組んでいます。このプロトコルは、メールボックスにアトミックデリバリーを提供するために使用される場合、SMTPの多くの制限に対処します。この提案の障害モードは、指定された管理メッセージのためのメッセージ1件のクォータ施行とメッセージストレージクォータオーバーライドの問題と同様に、慎重に制御されます。
An alternative approach is to misuse the IMAP protocol and use an IMAP-based submission mechanism to deposit a message directly into the recipient's inbox. This append must be done by a special super-user with write permissions into the recipient mailbox. Further, the message store must be able to trigger notification events upon insertion of a message into the mailbox via the Append command. The historic limitation on using IMAP4 for message sending involves the inability of IMAP to communicate a full SMTP envelope. For telephone answering, these limitations are not significant. However, the architectural issues raised by this approach are significant. See "Forward without Download Support" (Section 6.2.1).
別のアプローチは、IMAPプロトコルを誤用し、IMAPベースの提出メカニズムを使用して、受信者の受信トレイにメッセージを直接預けることです。この追加は、受信者のメールボックスに書き込み許可を備えた特別なスーパーユーザーによって行う必要があります。さらに、メッセージストアは、追加のコマンドを介してメッセージをメールボックスに挿入すると、通知イベントをトリガーできる必要があります。メッセージ送信にIMAP4を使用する歴史的な制限には、IMAPが完全なSMTPエンベロープを通信できないことが含まれます。電話の回答については、これらの制限は重要ではありません。ただし、このアプローチによって提起された建築上の問題は重要です。「ダウンロードサポートなしでフォワード」（セクション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.
他のサーバーにステータス情報を報告するサーバーのメッセージ通知の形式（例：IMAP4サーバーからSMSまたはPagerサーバーなど）を定義する必要があります。これらの通知を配信する方法も指定する必要があります。
The design for this MUST take into account the IAB note: "Unified Notification Protocol Considerations" (Appendix C).
この設計では、IABメモを考慮する必要があります：「統一された通知プロトコルの考慮事項」（付録C）。
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速度ワイヤレスハンドセットには、電子メールクライアントを実行する従来のシステム（PC）のCPUよりも劣る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ネットワークはこれを改善します。ただし、既存の電子メールクライアントには非常に大きなファイル（最大MBS）が必要です。これは、プレゼンテーション、画像、音声、ビデオなどのマルチメディア添付ファイルで遭遇します - モバイルはほとんどのデータを悪用できない場合でもダウンロードします（色の深さと画面サイズの制限）。このような大きなファイルを空中に転送することは、より高いワイヤレス帯域幅が利用できる場合でも、疑わしい価値があります。
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.
多くの場合、モバイルデータサービスのユーザーは、ハンドセットにダウンロードされたデータの量（Kilobytesなど）によって請求されます。ほとんどのユーザーは現在、ワイヤレスサービスよりもワイヤレスサービスでキロバイトごとのデータ料金が高くなっています。ユーザーは、ワイヤレスサービスのプレミアムに敏感です。これにより、携帯電話に大量の不必要なデータをダウンロードすることは不本意になり、選択したコンテンツのみをダウンロードできることを望みます。
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.
ワイヤレス端子は現在、ディスプレイサイズ、色の深さ、マルチメディア要素を提示する機能が制限されています（つまり、複数の写真が送信される場合、モバイルは通常、複数の画像要素ではなく、一度に1つの縮小された画像要素のみを表示できます。従来の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 Office（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).
この要件は、「ダウンロードサポートなし」で説明されているTUI要件と同じです（セクション6.2.1）。
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サイズが小さいo CPU消費において効率的oランタイムメモリ消費に効率的です
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.
1つの方法は、受信携帯電話の機能に対するメッセージを最適化するために、メッセージ取得の前にサーバーによるコンテンツトランスコーディングとメディア適応を使用することです。
Another possible optimization is to make the mobile email protocol itself simple, containing as little overhead as possible.
もう1つの最適化は、できるだけ少ないオーバーヘッドを含むモバイルメールプロトコル自体をシンプルにすることです。
A third approach is to minimize the bandwidth usage as described in "Avoid Content-Transfer-Encoding Data Inflation" (Section 6.1.1.2).
3番目のアプローチは、「コンテンツトランスファーをエンコードするデータのインフレを回避」（セクション6.1.1.2）で説明されているように、帯域幅の使用を最小限に抑えることです。
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.
メッセージ取得のプッシュモデルがサポートされている場合、選択的なダウンロードとスパム制御の必要性が特に重要です。
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]）は、MM1からMM7にラベル付けされた7つのインターフェイスを以下に定義します。
3GPP MMS Reference Architecture (subset)
3GPPMMSリファレンスアーキテクチャ（サブセット）
|---------| |------------|
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
MMS-マルチメディアメッセージングサービスUMS -UnifiedメッセージングサービスHLR-ホームロケーションレジスタDB-データベースVAS-付加サービスアプリ - アプリケーション
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)
3GPPMMSリファレンスアーキテクチャ（サブセット）
|---------| |------------|
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
MMS-マルチメディアメッセージングサービスUMS -UnifiedメッセージングサービスHLR-ホームロケーションレジスタDB-データベースVAS-付加サービスアプリ - アプリケーション
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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[2] Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August 1982.
[2] Crocker、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。、「配信ステータス通知（DSNS）のSimple Mail Transfer Protocol（SMTP）サービス拡張」、RFC 3461、2003年1月。
[4] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996.
[4] Myers、J。およびM. Rose、「郵便局プロトコル - バージョン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] Freed、N。およびN. Borenstein、「多目的インターネットメール拡張機能（MIME）パート1：インターネットメッセージボディの形式」、RFC 2045、1996年11月。
[6] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[6] Freed、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：ASSASCIIテキストのメッセージヘッダー拡張機能」、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] Freed、N.、Klensin、J。、およびJ. Postel、「多目的インターネットメール拡張機能（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] Freed、N。およびN. Borenstein、「多目的インターネットメール拡張機能（MIME）パート5：適合基準と例」、RFC 2049、1996年11月。
[10] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[10] Crispin、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] Hansen、T。およびG. Vaudreuil、「メッセージ処分通知」、RFC 3798、2004年5月。
[13] Vaudreuil, G. and G. Parsons, "Voice Profile for Internet Mail - version 2 (VPIMv2)", RFC 3801, June 2004.
[13] Vaudreuil、G。およびG. Parsons、「インターネットメールの音声プロファイル - バージョン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] Vaudreuil、G。およびG. Parsons、「Toll Quality Voice -32 Kbit/s適応型差動パルスコード変調（ADPCM）MIMEサブタイプ登録」、RFC 3802、2004年6月。
[15] Vaudreuil, G. and G. Parsons, "Content Duration MIME Header Definition", RFC 3803, June 2004.
[15] Vaudreuil、G。およびG. Parsons、「コンテンツ期間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] Buckley、R.、Venable、D.、McIntyre、L.、Parsons、G。、およびJ. Rafferty、「Internet Faxのファイル形式」、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] Parsons、G。and J. Rafferty、「タグイメージファイル形式（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。、「インターネットメールの最小ファックスアドレス形式」、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] Toyoda、K.、Ohno、H.、Murai、J。、およびD. Wing、「インターネットメールを使用したファクシミリの単純なモード」、RFC 3965、2004年12月。
[21] Parsons, G. and J. Rafferty, "Tag Image File Format (TIFF) - F Profile for Facsimile", RFC 2306, March 1998.
[21] Parsons、G。およびJ. Rafferty、「タグイメージファイル形式（TIFF）-Fファクシミリのプロファイル」、RFC 2306、1998年3月。
[22] Gellens, R. and J. Klensin, "Message Submission", RFC 2476, December 1998.
[22] Gellens、R。およびJ. Klensin、「Message Submission」、RFC 2476、1998年12月。
[23] Masinter, L. and D. Wing, " Extended Facsimile Using Internet Mail", RFC 2532, March 1999.
[23] Masinter、L。およびD. Wing、「インターネットメールを使用した拡張ファクシミリ」、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] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、 "HyperText Transfer Protocol-HTTP/1.1"、RFC 2616、1999年6月。
[25] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[25] Klensin、J。、「Simple Mail Transfer Protocol」、RFC 2821、2001年4月。
[26] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[26] Resnick、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] Burger、E.、Candell、E.、Eliot、C。、およびG. Klyne、「インターネットメールのメッセージコンテキスト」、RFC 3458、2003年1月。
[28] Burger, E., "Critical Content Multi-purpose Internet Mail Extensions (MIME) Parameter", RFC 3459, January 2003.
[28] Burger、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] Toyoda、K。およびD. Crocker、「FAXコンテンツネゴシエーションのSMTPサービス拡張」、2003年2月、Work in Progress。
[34] McRae, S. and G. Parsons, "Internet Voice Messaging (IVM)", RFC 4239, November 2005.
[34] McRae、S。およびG. Parsons、「インターネット音声メッセージング（IVM）」、RFC 4239、2005年11月。
[35] Murchison, K. and L. Greenfield, "LMTP Service Extension for Ignoring Recipient Quotas", Work in Progress, June 2002.
[35] Murchison、K。およびL. Greenfield、「レシピエントクォータを無視するためのLMTPサービス拡張」、2002年6月、進行中の作業。
[36] Crispin, M., "Message Submission", Work in Progress, February 2004.
[36] Crispin、M。、「メッセージ提出」、作業中の2004年2月。
[37] Newman, C., "Message Submission with Composition", Work in Progress, February 2004.
[37] Newman、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] Resnick、P。、「インターネットメッセージアクセスプロトコル（IMAP）Catenate Extension」、2003年12月、進行中の作業。
[40] Crispin, M. and C. Newman, "Internet Message Access (IMAP) - URLAUTH Extension", Work in Progress, July 2004.
[40] Crispin、M。and C. Newman、「インターネットメッセージアクセス（IMAP） - Urlauth Extension」、2004年7月、進行中の作業。
[41] Newman, D., "Message Submission BURL Extension", Work in Progress, July 2004.
[41] Newman、D。、「メッセージ提出Burl Extension」、2004年7月、進行中の作業。
[42] Crocker, D., "Internet Mail Architecture", Work in Progress, July 2004.
[42] Crocker、D。、「インターネットメールアーキテクチャ」、2004年7月、進行中の作業。
[43] Leuca, I., "Multimedia Messaging Service", Presentation to the VPIM WG, IETF53 Proceedings , April 2002.
[43] Leuca、I。、「マルチメディアメッセージングサービス」、VPIM WGへのプレゼンテーション、IETF53 Proceedings、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] Mahy、R。、「セッション開始プロトコル（SIP）のメッセージの概要とメッセージ待機表示イベントパッケージ」、RFC 3842、2004年8月。
[45] Shapira, N. and E. Aloni, "Simple Notification and Alarm Protocol (SNAP)", Work in Progress, December 2001.
[45] Shapira、N。およびE. Aloni、「Simple Notification and Alarm Protocol（SNAP）」、2001年12月、進行中の作業。
[46] Vaudreuil, G., "Messaging profile for telephone-based Messaging clients", Work in Progress, February 2002.
[46] Vaudreuil、G。、「電話ベースのメッセージングクライアントのメッセージングプロファイル」、2002年2月、進行中の作業。
[47] Burger, E., "Internet Unified Messaging Requirements", Work in Progress, February 2002.
[47] Burger、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」、Open Mobile Alliance（OMA）OMA-WAP-MMS-V1_1- 20021101-C、2002年11月。
[49] OMA, "Push Architectural Overview", Open Mobile Alliance (OMA) WAP-250-PushArchOverview-20010703-a, July 2001.
[49] OMA、「Push Architectural Overview」、Open Mobile Alliance（OMA）WAP-250-PusharchView-20010703-A、2001年7月。
[50] OMA, "Push Access Protocol Specification", Open Mobile Alliance (OMA) WAP-247-PAP-20010429-a, April 2001.
[50] OMA、「プッシュアクセスプロトコル仕様」、Open Mobile Alliance（OMA）WAP-247-PAP-20010429-A、2001年4月。
[51] OMA, "Push Proxy Gateway Service Specification", Open Mobile Alliance (OMA) WAP-249-PPGService-20010713a, July 2001.
[51] OMA、「Push Proxy Gateway Service Specification」、Open Mobile Alliance（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」、Open Mobile Alliance（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」、Open Mobile Alliance（OMA）OMA-MMS-ENC-V1_- 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」、Open Mobile Alliance（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」、Open Mobile Alliance（OMA）OMA-Nem-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、「第3世代パートナーシッププロジェクト、技術仕様グループサービスとシステムの側面、サービスの側面、機能的説明、ステージ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、「第3世代パートナーシッププロジェクト、技術仕様グループターミナル、マルチメディアメッセージングサービス（MMS）;機能説明;ステージ2 "、3GPP TS 23.140、2001。
[58] 3GPP2, "Short Message Service (SMS)", 3GPP2 TSG C.S0015-0, December 1999.
[58] 3GPP2、「Short Message Service（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：シグナリングシステムNo. 7の仕様」、CCITT White Book、Volume VI、Faccle VI.7。
[61] CCITT, "Recommendations Q.721-Q.766: Specifications of Signalling System No.7", CCITT White Book, Volume VI, Fascicle VI.8.
[61] CCITT、「推奨事項Q.721-Q.766：シグナリングシステムNo.7の仕様」、Ccitt White Book、Volume VI、Faccle 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.
[63] ITU、「信号システム番号7の仕様」、ITUホワイトブック、ITU-T推奨Q.763。
[64] ITU, "Interface between Data Terminal Equipment (DTE) and Data Circuit-terminating Equipment (DCE) for terminals operating in the packet mode and connected to public data networks by dedicated circuit", ITU-T Recommendation X.25, October 1996.
[64] ITU、「パケットモードで動作し、専用回路でパブリックデータネットワークに接続された端子用のデータ端子機器（DTE）とデータ回路終了機器（DCE）の間のインターフェース」、ITU-T推奨X.25、1996年10月。
[65] BELLCORE, "Specifications of Signalling System Number 7", GR-246-CORE Issue 1, December 1994.
[65] Bellcore、「シグナリングシステム番号7の仕様」、GR-246コア問題1、1994年12月。
Eric Burger Brooktrout Technology, Inc. 18 Keewaydin Dr. Salem, MA 03079 USA
Eric Burger Brooktrout Technology、Inc。18 Keewaydin Dr. Salem、MA 03079 USA
Phone: +1 603 890-7587
EMail: eburger@brooktrout.com
Yair Grosu Comverse 29 Habarzel St. Tel-Aviv 69710 Israel
Yair Grosu Comverse 29 Habarzel St. Tel-Aviv 69710イスラエル
EMail: Yair.Grosu@comverse.com
Glenn Parsons Nortel Networks P.O. Box 3511 Station C Ottawa, ON K1Y 4H7 Canada
グレンパーソンズノルテルネットワークP.O.ボックス3511ステーションCオタワ、K1Y 4H7カナダ
Phone: +1 613 763-7582
EMail: gparsons@nortelnetworks.com
Milt Roselinsky Openwave Systems, Inc. 530 E. Montecito St. Santa Barbara, CA 93103 USA
Milt Roselinsky OpenWave Systems、Inc。530 E. Montecito St. Santa Barbara、CA 93103 USA
Phone: +1 805 884-6207
EMail: milt.roselinsky@openwave.com
Dan Shoshani Comverse 29 Habarzel St. Tel-Aviv 69710 Israel
Dan Shoshani Comverse 29 Habarzel St. Tel-Aviv 69710イスラエル
EMail: Dan.Shoshani@comverse.com
Alan K. Stebbens
Openwave Systems, Inc.
530 E. Montecito St.
Santa Barbara, CA 93103
USA
Phone: +1 805 884-3162
EMail: alan.stebbens@openwave.com
Gregory M. Vaudreuil Lucent Technologies 7291 Williamson Rd. Dallas, TX 75214 USA
Gregory M. Vaudreuil Lucent Technologies 7291 Williamson Rd。テキサス州ダラス75214 USA
Phone: +1 214 823-9325
EMail: GregV@ieee.org
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.
Ari ErevとNoam Shapira（両方ともComverseから）は、IMAPが電話ベース（TUI）メッセージングクライアントをサポートするために実質的な要件を提供しました。Meir Mendelovich（Comverse）は、ワイヤレス要件セクションの統合を支援しました。Benjamin Ellsworth（OpenWave）は、モバイルメッセージングアーキテクチャと要件に貢献しました。Yaacov（Jerry）Weingarten（Comverse）とStephane Maes（Oracle）は、最終文書に関する詳細なコメントを提供しました。
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要求に応じて策定されました。次の資料を参照として使用しました： * Draft-Dusseault-S2S-Event-Reqs-00.txt（通知要件） * IETF 56のレモネードWGの会議ノート。ジェネリック通知プロトコルのいくつかの側面があるSNAP） *レモネードWGチャーター *レモネードリストの最近のメール * 1998年のUCIワークショップのインターネット全体の通知のいくつかのプレゼンテーション
* The Web pages for KnowHow, a company founded by Rohit Khare which has a proprietary Internet-wide notification system.
* ノウハウのWebページは、独自のインターネット全体の通知システムを備えたRohit Khareによって設立された会社です。
Thanks to Lisa Dusseault for providing these references.
これらの参照を提供してくれたLisa Dusseaultに感謝します。
Note that this opinion does not represent IAB concensus, it is just the opinion of the author after having reviewed the references.
この意見はIABコンセンサスを表していないことに注意してください。それは、参照をレビューした後の著者の意見にすぎません。
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上のOlay/ ComやTooltalkのようなデスクトップアプリケーション統合メカニズムについて尋ねられたのと同じように、同じ種類の機能が一般的な通知プロトコルから求められているように見えましたが、メッセージングのレベルではインターネットを横切って。さまざまなアプリケーション固有のメカニズムを備えたさまざまな分散アプリケーションが、各アプリケーションを互いのアプリケーションと対話させるというn x nの問題を持たずに相互運用できるはずです。IETF 56のレモネードへのLisa Dusseaultによるプレゼンテーションにある砲の例は、XMPPインスタントメッセージングのような1つのアプリケーションから通知を送信し、SMSのように受信者がたまたま使用していたあらゆるデバイスで配信することです。携帯電話で。
The usual problem with application intergration mechanisms on the desktop is how to get the various applications to actually use the mechanism. For Windows, this is relatively easy, since most application developers see major value-added in their applications being able to play nicely with Microsoft Office. For Tooltalk, unfortunatly, Solaris developers didn't see the 10x improvement, and so it was not used outside of Sun's internally maintained applications and a few flagship applications like Framemaker. If the generic notification mechanism requires application developers and other notification protocol designers to make a major effort to utilize it, including modifying their applications or protocols in some way, the protocol could become "just another notification mechanism" rather than a unifying device, because most application developers and other protocol designers could ignore it.
デスクトップ上のアプリケーション間のグレーションメカニズムの通常の問題は、さまざまなアプリケーションを実際に使用してメカニズムを使用する方法です。Windowsの場合、これは比較的簡単です。ほとんどのアプリケーション開発者は、Microsoft Officeでうまくプレイできるアプリケーションで主要な付加価値があるからです。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-Snap-05.txtの図1を見ると、答えは、通知クライアントが一般的なプロトコル、この場合はスナップ、機能エンティティ（受信クライアントのサーバー？モジュールを使用しますか？）一般的な通知をアプリケーション固有の通知に処理する「通知サービス」と呼ばれ、その通知をクライアントに送信します。この図から、通知クライアントは変更が必要であるように見えますが、受信クライアントはそうしません。
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.
アプリケーション統合のもう1つの特徴メカンシムは、通常、非常に単純な操作に焦点を当てており、そのセマンティクスは異なるアプリケーション間で共有されていることです。例は、「ここに長方形で、自分自身を表示します」または「このスタイルのテキストオブジェクトをクリップボードに入れます」と、アプリケーションがスタイルのテキストの意味に同意します。より複雑なセマンティクスは、各アプリケーションがオブジェクトのコレクション上の特定の一連の操作の意味に独自の特にひねりを加えているため、共有するのは困難です。その結果、統合メカニズムの「最も一般的な分母」コレクションが生じ、主にディスプレイ統合に焦点を当て、程度は低い程度に統合をカットして貼り付けます。
In the context of a generic notification protocol, this raises several possible issues. One is addressing, which is identified draft-dusseault-s2s-event-reqs-00.txt, but in a sense this is the easiest to resolve, by using existing and perhaps newly defined URIs. A more complex problem is matching the semantics of what preconditions constitute the trigger for an event across different application notification mechanisms. This is of course necessary for translating notifications between the different event notification mechanisms and the generic mechanism, but, more problematically, it is also required for a subscription service whereby subscriptions can be made to filter events using the generic notification mechanism and the subscriptions can be translated to different application specific mechanisms. Any language for expressing generic subscriptions is unlikely to support expressing the fine points in the different application notification semantics. Note that SNAP does not seem to support a subscription service so perhaps this isn't an issue for SNAP.
一般的な通知プロトコルのコンテキストでは、これによりいくつかの可能な問題が発生します。1つはアドレス指定です。これは、Draft-Dusseault-S2S-Event-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.他のいくつかのトピックはゲートウェイです。上記の砲の例（XMPPを使用して送信され、携帯電話でSMSを介して到着するメッセージ）は、実際にはゲートウェイの例です。この目的のために統一された通知メカニズムを使用することの問題は、2つの間に共通の他の機能がある場合、とにかくゲートウェイが構築される可能性が高いことです。実際、レモネードの作業項目の1つは、そのようなゲートウェイを調査することです。したがって、一般的な通知メカニズムの値は、これに照らして評価する必要があります。
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.
これらは主要な建築上の問題ですが、主要なシステム開発の取り組みに考慮する必要がある他のいくつかがあります。End to End Securityは、Draft-Dusseault-S2S-Event-Reqs-00.txtがこれについて非常に広範囲に語っているため、ここで繰り返されることはありません。主な問題は、一般的な中間プロトコルを介した通知の移動に直面して、エンドツーエンドセキュリティプロパティが維持されることを保証する方法です。別の問題はスケーラビリティです。ピアツーピアV.S.サーバーベースのメカニズムには、通知メカニズムがどれほどスケーラブルであるかに影響があり、これには検討が必要です。拡張性は慎重に検討する必要があります。新しいアプリケーションを統合するには何が必要ですか？理想的には、時間とともに、アプリケーション開発者は「独自の通知サービスの展開を停止し、一般的なサービスを使用するだけですが、この理想は達成が非常に難しく、市場の受け入れに大きく依存する可能性があります。
Finally, there are some considerations that aren't architectural but may impact the ultimate success of a generic notification protocol, in the sense that the protocol becomes widely deployed and used. The author's experience is that IETF has not had particular success in introducing mechanisms that unify or supplant existing proprietary mechanisms unless strong vendor and service provider by-in is there. Two examples are instant messaging and service discovery. With instant messaging, it seems that a standarized, unified instant messaging protocol has been delayed by the lack of committment from major service providers. With service discovery, weak commitment from vendors has resulted in the continued introduction of vendor specific service discovery solutions even after an IETF standard is in place. The situation with service discovery (with which the author is most familiar) resulted from a lack of major vendor committment during the end phases of the standarization process. Applying these lessions to a generic notification protocol, having important players with proprietary notification protocols on board and committed until the conclusion of the design process will be crucial. Major committment is needed from various application notification protocols before a generic mechanism could succeed. Given the amount of time and effort required in any IETF standardization work, assessing these with an objective eye is critical, otherwise, regardless of how technically well designed the protocol is, deployment success may be lacking. Having an elegently design solution that nobody deploys is an outcome that might be wise to avoid.
最後に、建築的ではないが、プロトコルが広く展開され使用されるという意味で、一般的な通知プロトコルの究極の成功に影響を与える可能性のあるいくつかの考慮事項があります。著者の経験は、IETFが、強力なベンダーとサービスプロバイダーが存在しない限り、既存の独自のメカニズムを統合または取ってくれるメカニズムを導入することに特に成功していないことです。2つの例は、インスタントメッセージングとサービスの発見です。インスタントメッセージングを使用すると、主要なサービスプロバイダーからのコミットメントの欠如により、段階的で統一されたインスタントメッセージングプロトコルが遅れているようです。サービスの発見により、ベンダーからの弱いコミットメントにより、IETF標準が導入された後でも、ベンダー固有のサービスディスカバリーソリューションが継続的に導入されました。サービスの発見（著者が最もよく知られている）の状況は、傑出したプロセスの最終段階での主要なベンダーのコミットメントの欠如に起因しました。これらの膨張を一般的な通知プロトコルに適用し、独自の通知プロトコルを搭載した重要なプレーヤーを搭載し、設計プロセスの終了が重要になるまでコミットします。一般的なメカニズムが成功する前に、さまざまなアプリケーション通知プロトコルから主要なコミットメントが必要です。IETF標準化作業に必要な時間と労力の量を考えると、これらを客観的な目で評価することが重要です。そうでない場合、プロトコルが技術的に設計されていることに関係なく、展開の成功が欠けている可能性があります。誰も展開していない優雅なデザインソリューションを持つことは、避けるのが賢明かもしれない結果です。
James Kempf July 2003
2003年7月のJames Kempf
Author's Address
著者の連絡先
Jin Kue Wong (Editor) Nortel Networks P.O. Box 3511 Station C Ottawa, ON K1Y 4H7 Canada
Jin Kue Wong（編集者）Nortel Networks P.O.ボックス3511ステーションCオタワ、K1Y 4H7カナダ
Phone: +1 613 763-2515
EMail: j.k.wong@sympatico.ca
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。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）によって提供されます。