[要約] RFC 5442は、OMA Mobile Email（MEM）をサポートするためのLEMONADEアーキテクチャについての規格です。このRFCの目的は、インターネットメールを使用してOMA MEMを実現するためのアーキテクチャを提供することです。
Network Working Group E. Burger
Request for Comments: 5442 Consultant
Category: Informational G. Parsons
Nortel Networks
March 2009
LEMONADE Architecture - Supporting Open Mobile Alliance (OMA) Mobile Email (MEM) Using Internet Mail
レモネードアーキテクチャ - インターネットメールを使用したオープンモバイルアライアンス（OMA）モバイルメール（MEM）のサポート
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) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
このドキュメントは、BCP 78およびこのドキュメントの公開日（http://trustee.ietf.org/license-info）に有効なIETFドキュメントに関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの貢献からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得しないと、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版または英語以外の言語に翻訳する。
Abstract
概要
This document specifies the architecture for mobile email, as described by the Open Mobile Alliance (OMA), using Internet Mail protocols. This architecture was an important consideration for much of the work of the LEMONADE (Enhancements to Internet email to Support Diverse Service Environments) working group in the IETF. This document also describes how the LEMONADE architecture meets OMA's requirements for their Mobile Email (MEM) service.
このドキュメントは、インターネットメールプロトコルを使用して、Open Mobile Alliance（OMA）で説明されているように、モバイルメールのアーキテクチャを指定します。このアーキテクチャは、IETFのワーキンググループのワーキンググループ（多様なサービス環境をサポートするためのインターネットメールの強化）の作業の多くにおいて重要な考慮事項でした。このドキュメントでは、レモネードアーキテクチャがモバイルメール（MEM）サービスに対するOMAの要件をどのように満たしているかについても説明しています。
Table of Contents
目次
1. Introduction ....................................................2
2. OMA Mobile Email (MEM) ..........................................2
2.1. OMA MEM Requirements .......................................2
2.2. OMA MEM Architecture .......................................3
2.2.1. OMA MEM Logical Architecture ........................3
2.2.2. OMA MEM Deployment Issues ...........................4
2.3. OMA MEM Technical Specification ............................6
3. IETF LEMONADE Architecture ......................................6
3.1. Relationship between the OMA MEM and LEMONADE Logical
Architectures ..............................................7
3.2. LEMONADE Realization of OMA MEM with
non-LEMONADE-Compliant Servers .............................9
3.2.1. LEMONADE Realization of OMA MEM with
non-LEMONADE IMAP Servers ...........................9
3.2.2. LEMONADE Realization of OMA MEM with non-IMAP
Servers ............................................10
4. Filters and Server-to-Client Notifications and LEMONADE ........11
5. Security Considerations ........................................13
6. Acknowledgements ...............................................13
7. Informative References .........................................13
This document describes the architecture of OMA Mobile Email (MEM) using Internet Mail protocols defined by the IETF. The LEMONADE working group has enhanced many of these protocols for use in the mobile environment. The LEMONADE profile [PROFILE] and its revision, [PROFILE-bis], summarize such protocols and protocol use. This document shows how the OMA MEM Requirements document [MEM-req], OMA MEM Architecture [MEM-arch], and OMA MEM Technical Specification [MEM-ts] relate to the work of LEMONADE in the IETF.
このドキュメントでは、IETFによって定義されたインターネットメールプロトコルを使用して、OMAモバイルメール（MEM）のアーキテクチャについて説明します。レモネードワーキンググループは、モバイル環境で使用するためにこれらのプロトコルの多くを強化しました。レモネードプロファイル[プロファイル]とそのリビジョン[プロファイル]は、そのようなプロトコルとプロトコルの使用を要約します。このドキュメントは、OMA MEM要件ドキュメント[MEM-REQ]、OMA MEM Architecture [Mem-Arch]、およびOMA MEMテクニカル仕様[MEM-TS]がIETFのレモネードの作業とどのように関連しているかを示しています。
The OMA Mobile Email (MEM) sub-working group has spent some time studying the requirements and architecture of mobile email. IETF LEMONADE has been liaising with them and has based much of its Internet Mail enhancements on their input. This section summarizes the output of the OMA.
OMAモバイルメール（MEM）サブワーキンググループは、モバイルメールの要件とアーキテクチャの研究にしばらく時間を費やしました。IETFレモネードは彼らと連絡を取り合っており、インターネットメールの強化の多くを入力に基づいています。このセクションでは、OMAの出力をまとめます。
The OMA MEM activity collected a set of use cases and derived requirements for a Mobile Email (MEM) enabler. The OMA MEM Requirements document [MEM-req] summarizes this work. Some requirements relate to email protocols, some involve other OMA technologies outside the scope of the IETF, and some relate to implementations and normative interoperability statements for clients and servers.
OMA MEMアクティビティは、モバイルメール（MEM）イネーブラーのユースケースのセットと派生要件を収集しました。OMA MEM要件ドキュメント[MEM-REQ]は、この作業を要約しています。いくつかの要件は電子メールプロトコルに関連し、一部はIETFの範囲外の他のOMAテクノロジーを含み、一部はクライアントとサーバーの実装と規範的な相互運用性ステートメントに関連しています。
This section introduces the OMA MEM Architecture.
このセクションでは、OMA MEMアーキテクチャを紹介します。
The OMA MEM activity has derived a logical architecture from the requirements and use cases described in [MEM-req]. A simplification for illustrative purposes is shown in Figure 1, where arrows indicate content flows.
OMA MEMアクティビティは、[Mem-Req]で説明されている要件とユースケースから論理アーキテクチャを導き出しました。例の目的の単純化を図1に示します。矢印はコンテンツの流れを示しています。
__________
| Other |
+---| Mobile |<--+
| | Enablers | |
| |__________| |
|ME-4 |ME-3
_v____ ___v____ ________
| |ME-1 | | | |
| MEM |-------->| MEM | I2 | Email |
|Client| ME-2| Server |<---->| Server |
|______|<--------|________| |________|
^
|ME-5
|
Figure 1: Basic OMA MEM Logical Architecture
図1：基本的なOMA MEM論理アーキテクチャ
Figure 1 identifies the following elements:
図1は、次の要素を示しています。
o The MEM client that implements the client-side functionality of the OMA Mobile Email enabler. It is also responsible for providing the mobile email user experience and interface to the user and storing the email and data to be sent to the MEM server when not connected.
o OMAモバイルメールイネーブラーのクライアント側の機能を実装するMEMクライアント。また、モバイルメールのユーザーエクスペリエンスとインターフェイスをユーザーに提供し、接続されていないときにMEMサーバーに送信されるメールとデータを保存する責任があります。
o The MEM server that implements the server-side functionality of the OMA Mobile Email (MEM) enabler.
o OMAモバイルメール（MEM）イネーブラーのサーバー側の機能を実装するMEMサーバー。
o The MEM protocol between the MEM client and MEM server. It is responsible for all the in-band data exchanges that take place between the MEM client and server in order to update the MEM client with email server changes and the email server with changes in the MEM client, and in order to send new email from the email server.
o MEMクライアントとMEMサーバーの間のMEMプロトコル。MEMクライアントとサーバーの間で行われるすべてのインバンドデータ交換は、MEMクライアントを電子メールサーバーの変更で更新し、MEMクライアントの変更を伴う電子メールサーバーを更新し、新しい電子メールを送信するために責任を負います。電子メールサーバー。
o Other OMA enablers that are needed to directly support the Mobile Email enabler. They are out of the scope of the IETF but may include support for:
o モバイルメールイネーブラーを直接サポートするために必要な他のOMAイネーブラー。それらはIETFの範囲外ですが、以下のサポートが含まれる場合があります。
* Client provisioning and management for over-the-air installation of the MEM client on the device, provisioning of the client settings, and revocation of client privileges.
* クライアントのプロビジョニングと管理デバイスにMEMクライアントのオーバーザエアインストール、クライアント設定のプロビジョニング、クライアント特権の取り消し。
* Messaging enablers for out-of-band notification, where out-of-band notifications that are server-to-client event exchanges are not transported by the MEM protocol but via other channels.
* 帯域外通知のためのメッセージングイネーブラー。サーバーからクライアントのイベント交換であるバンド外通知は、MEMプロトコルによってではなく、他のチャネルを介して輸送されます。
* Billing, charging, and so on.
* 請求、請求など。
OMA identifies different interfaces:
OMAはさまざまなインターフェイスを識別します。
o ME-1: MEM client interface to interact via the MEM protocol with the MEM server.
o ME-1：MEM Serverを使用したMEMプロトコルを介して対話するMEMクライアントインターフェイス。
o ME-2: Corresponding interface of the MEM server.
o ME-2：MEMサーバーの対応するインターフェイス。
o ME-3: Out-of-band MEM server interfaces; for example, to support generation of server-to-client notifications.
o ME-3：バンド外のMEMサーバーインターフェイス。たとえば、サーバーからクライアントの通知の生成をサポートします。
o ME-4: Out-of-band MEM client interfaces (e.g., to receive server-to-client notifications).
o ME-4：バンド外のMEMクライアントインターフェイス（たとえば、サーバーからクライアントへの通知を受信するため）。
o ME-5: Interface for management of MEM enabler server settings, user preferences, and filters, globally and per account.
o ME-5：MEM Enabler Serverの設定、ユーザー設定、フィルターの管理のためのインターフェイス、グローバルおよびアカウントごと。
The MEM server enables an email server. In a particular implementation, the email server may be packaged with (internal to it) the MEM server or be a separate component. In such cases, interfaces to the email server are out of scope of the OMA MEM specifications. In the present document, we focus on the case where the backend consists of IETF IMAP and SUBMIT servers. However, we also discuss the relationship to other cases. The I2 interface is an OMA notation to designate protocol / interfaces that are not specified by the MEM enabler but may be standardized elsewhere.
MEMサーバーは電子メールサーバーを有効にします。特定の実装では、電子メールサーバーはMEMサーバー（内部）でパッケージ化されたり、別のコンポーネントになったりする場合があります。このような場合、電子メールサーバーへのインターフェイスは、OMA MEM仕様の範囲外です。現在のドキュメントでは、バックエンドがIETF IMAPで構成され、サーバーを送信する場合に焦点を当てます。ただし、他のケースとの関係についても説明します。i2インターフェイスは、MEMイネーブラーによって指定されていないが、他の場所で標準化される可能性のあるプロトコル /インターフェイスを指定するOMA表記です。
The OMA MEM Architecture document [MEM-arch] further identifies deployment models.
OMA MEMアーキテクチャドキュメント[MEM-ARCH]は、展開モデルをさらに識別します。
The OMA MEM Architecture document [MEM-arch] identifies OMA MEM server proxies as server components that may be deployed ahead of firewalls to facilitate firewall traversal.
OMA MEMアーキテクチャドキュメント[MEM-ARCH]は、Firewallsの前に展開される可能性のあるサーバーコンポーネントとしてOMA MEMサーバープロキシを識別し、ファイアウォールのトラバーサルを促進します。
OMA MEM identifies that each component (MEM client, MEM servers, other enablers, and the email server) may be deployed in different domains, possibly separated by firewalls and other network intermediaries. MEM proxies may be involved in front of a firewall that protects the MEM server domain.
OMA MEMは、各コンポーネント（MEMクライアント、MEMサーバー、その他のイネーブラー、および電子メールサーバー）がさまざまなドメインに展開される可能性があることを特定します。MEMプロキシは、MEMサーバードメインを保護するファイアウォールの前に関与する可能性があります。
OMA MEM targets support of configurations where:
OMA MEMは、構成のサポートをターゲットにします。
o All components are within the same domain, such as in a mobile operator.
o すべてのコンポーネントは、モバイルオペレーターなど、同じドメイン内にあります。
o The MEM client and other enablers are in the mobile operator domain, there is a MEM proxy, and the MEM server and email server are in the domain of the email service provider.
o MEMクライアントとその他のイネーブラーはモバイルオペレータードメインにあり、MEMプロキシがあり、MEMサーバーと電子メールサーバーは電子メールサービスプロバイダーのドメインにあります。
o The MEM client and other enablers as well as a MEM proxy are in the mobile operator domain, and the MEM server and email server are in the domain of the email service provider.
o MEMクライアントとその他のイネーブラー、およびMEMプロキシはモバイルオペレータードメインにあり、MEMサーバーと電子メールサーバーは電子メールサービスプロバイダーのドメインにあります。
o The MEM client and other enablers are in the mobile operator domain, a MEM proxy is in a third-party service provider domain, and the MEM server and email server are in the domain of the email service provider.
o MEMクライアントと他のイネーブラーはモバイルオペレータードメインにあり、MEMプロキシはサードパーティサービスプロバイダードメインにあり、MEM Serverと電子メールサーバーは電子メールサービスプロバイダーのドメインにあります。
o The MEM client, other enabler, and MEM server are in the mobile operator domain, and the email server is in the domain of the email service provider.
o MEMクライアント、その他のイネーブラー、およびMEMサーバーはモバイルオペレータードメインにあり、電子メールサーバーは電子メールサービスプロバイダーのドメインにあります。
o The MEM client and other enablers are in the mobile operator domain, the MEM server is in a third-party service provider domain, and the email server is in the domain of the email service provider.
o MEMクライアントと他のイネーブラーはモバイルオペレータードメインにあり、MEMサーバーはサードパーティサービスプロバイダードメインにあり、電子メールサーバーは電子メールサービスプロバイダーのドメインにあります。
The email service provider can be a third-party service provider, a network service provider, or an enterprise email service.
電子メールサービスプロバイダーは、サードパーティのサービスプロバイダー、ネットワークサービスプロバイダー、またはエンタープライズメールサービスです。
The OMA MEM activity will conclude with a specification for a Mobile Email (MEM) enabler. The ongoing work is in the OMA MEM Technical Specification [MEM-ts]. LEMONADE is a basis for the mechanism. However, some additional details that are outside the scope of the IETF will also be included.
OMA MEMアクティビティは、モバイルメール（MEM）イネーブラーの仕様で終了します。進行中の作業は、OMA MEMテクニカル仕様[MEM-TS]にあります。レモネードはメカニズムの基礎です。ただし、IETFの範囲外にあるいくつかの追加の詳細も含まれます。
OMA provides ways to perform provisioning via OMA client provisioning and device management. Other provisioning specifications are available (e.g., SMS based).
OMAは、OMAクライアントのプロビジョニングとデバイス管理を介してプロビジョニングを実行する方法を提供します。その他のプロビジョニング仕様が利用可能です（例：SMSベース）。
OMA provides enablers to support out-of-band notification mechanisms, filter specifications (such as XDM), and remote deactivate devices, and to perform other non-Internet activities.
OMAは、帯域外通知メカニズム、フィルター仕様（XDMなど）、およびリモート非アクティブ化デバイスをサポートし、他の非インターネットアクティビティを実行することを可能にします。
This section introduces the LEMONADE Architecture.
このセクションでは、レモネードアーキテクチャを紹介します。
The IETF LEMONADE activity has derived a LEMONADE profile [PROFILE-bis] with the logical architecture represented in Figure 2, where arrows indicate content flows.
IETFレモネードアクティビティは、図2に表される論理アーキテクチャを使用して、レモネードプロファイル[プロファイルビス]を導き出しました。矢印はコンテンツの流れを示しています。
______________
| |
_________| Notification |
| | Mechanism |
| |______________|
|Notif. ^
|Protocol |
| ___|______
| | | _____
__v__ IMAP | LEMONADE | ESMTP | |
| |<----------->| IMAP |<---------------| MTA |
| MUA |- | Store | |_____|
|_____| \ |__________|
\ |
\ |URLAUTH
\SUBMIT |
\ ____v_____
\ | | _____
\ | LEMONADE | ESMTP | |
---->| Submit |--------------->| MTA |
| Server | |_____|
|__________|
Figure 2: LEMONADE logical architecture
図2：レモネード論理アーキテクチャ
The LEMONADE profile [PROFILE] assumes:
レモネードプロファイル[プロファイル]を想定しています：
o IMAP protocol [RFC3501], including LEMONADE profile extensions [PROFILE].
o IMAPプロトコル[RFC3501]、レモネードプロファイル拡張[プロファイル]を含む。
o SUBMIT protocol [RFC4409], including LEMONADE profile extensions.
o レモネードプロファイル拡張機能を含むプロトコル[RFC4409]を送信します。
o LEMONADE profile compliant IMAP store connected to an MTA (Mail Transfer Agent) via the ESMTP [EMAIL].
o ESMTP [メール]を介してMTA（メール転送エージェント）に接続されたレモネードプロファイルに準拠したIMAPストア。
o LEMONADE profile compliant submit server connected to an MTA, often via the ESMTP.
o 多くの場合、ESMTPを介して、MTAに接続されたレモネードプロファイルコンプライアント送信サーバー。
o Out-of-band server-to-client notifications relying on external notification mechanisms (and notification protocols) that may be out of the scope of the LEMONADE profile.
o レモネードプロファイルの範囲外である可能性のある外部通知メカニズム（および通知プロトコル）に依存する帯域外サーバーからクライアントへの通知。
o LEMONADE-aware MUA (Mail User Agent). While use of out-of-band notification is described in the LEMONADE profile, support for the underlying notifications mechanisms/protocols is out of the scope of the LEMONADE specifications.
o レモネードアウェアMUA（メールユーザーエージェント）。バンド外通知の使用はレモネードプロファイルで説明されていますが、基礎となる通知メカニズム/プロトコルのサポートはレモネード仕様の範囲外です。
Further details on the IETF email protocol stack and architecture can be found in [MAIL].
IETF電子メールプロトコルスタックとアーキテクチャの詳細については、[メール]をご覧ください。
Figure 3 illustrates the mapping of the IETF LEMONADE logical architecture on the OMA MEM logical architecture.
図3は、OMA MEM論理アーキテクチャに関するIETFレモネード論理アーキテクチャのマッピングを示しています。
_____________________
| Other_Mob. Enablers |
| |--------------| |
_________| Notification | |
| | | Mechanism | |
| | |______________| |
|Notif. |____________^________|
|Protocol ______|__________
ME-4 | | ___|_ME-3_ |
___|____ | | | | _____
| __v__ | IMAP | | LEMONADE | | ESMTP | |
|| |<----------->| IMAP |<-----------| MTA |
|| MUA || ME-2a | | Store | | |_____|
||_____||\ME-1 | |__________| |
| MEM | \ | | |
| Client| \ | |URLAUTH |
|_______| \SUBMIT | |
\ | ____v_____ |
\ | | | | _____
\ | | LEMONADE | | ESMTP | |
---->| Submit |----------->| MTA |
ME-2b | | Server | | |_____|
| |__________| |
|MEM Email |
|Server Server|
|_________________|
^
|ME-5
|
Figure 3: Mapping of LEMONADE Logical Architecture onto the OMA MEM Logical Architecture
図3：OMA MEM論理アーキテクチャへのレモネード論理アーキテクチャのマッピング
As described in Section 3, the LEMONADE profile assumes LEMONADE profile compliant IMAP stores and SUBMIT servers. Because the LEMONADE profile extends the IMAP store and the SUBMIT server, the mobile enablement of email provided by the LEMONADE profile is directly provided in these servers. Mapping to the OMA MEM logical architecture for the case considered and specified by the LEMONADE profile, we logically combine the MEM server and email server. However, in LEMONADE we split them logically into a distinct LEMONADE message store and a LEMONADE SUBMIT server. ME-2 consists of two interfaces. ME-2a is IMAP extended according to the LEMONADE profile. ME-2b is SUBMIT extended according to the LEMONADE profile.
セクション3で説明されているように、レモネードプロファイルは、レモネードプロファイルに準拠したIMAPストアを想定し、サーバーを送信します。レモネードプロファイルはIMAPストアと送信サーバーを拡張するため、レモネードプロファイルによって提供される電子メールのモバイルイネーブルメントがこれらのサーバーに直接提供されます。レモネードプロファイルによって検討および指定されたケースのOMA MEM論理アーキテクチャへのマッピングでは、MEMサーバーと電子メールサーバーを論理的に組み合わせます。ただし、レモネードでは、それらを異なるレモネードメッセージストアとレモネード送信サーバーに論理的に分割します。ME-2は2つのインターフェイスで構成されています。ME-2Aは、レモネードプロファイルに従って拡張されています。ME-2Bは、レモネードプロファイルに従って拡張されます。
The MUA is part of the MEM client.
MUAはMEMクライアントの一部です。
The external notifications mechanism is part of the OMA enablers specified by the OMA.
外部通知メカニズムは、OMAによって指定されたOMAイネーブラーの一部です。
The OMA MEM activity is not limited to enabling LEMONADE-compliant servers. It explicitly identifies the need to support other backends. This is, of course, outside the scope of the IETF LEMONADE activity.
OMA MEMアクティビティは、レモネードに準拠したサーバーを有効にすることに限定されません。他のバックエンドをサポートする必要性を明示的に識別します。もちろん、これはIETFレモネードアクティビティの範囲外です。
Figure 4 illustrates the case of IMAP servers that are not LEMONADE-compliant. In such case, the I2 interface between the MEM server components and the IMAP store and SUBMIT server are IMAP and SUBMIT without LEMONADE extensions.
図4は、レモネードに準拠していないIMAPサーバーのケースを示しています。そのような場合、MEMサーバーコンポーネントとIMAPストアと送信サーバーの間のI2インターフェイスは、Lemonade ExtensionsなしでIMAPおよび送信されます。
It is important to note the realizations are of a schematic nature and do not dictate actual implementation. For example, one could envision collocating the LEMONADE MEM enabler server and the submit server shown in Figure 4 in a single instantiation of the implementation. Likewise, we consciously label the LEMONADE MEM enabler as neither an IMAP proxy nor an IMAP back-to-back user agent. LEMONADE leaves the actual implementation to the developer.
実現は概略的な性質であり、実際の実装を決定しないことに注意することが重要です。たとえば、実装の単一のインスタンス化で、図4に示すレモネードMEMイネーブラーサーバーと送信サーバーをコロケートすることを想定できます。同様に、レモネードMEMイネーブラーをIMAPプロキシでも、IMAPの連続したユーザーエージェントのいずれでもないと意識的にラベル付けします。レモネードは実際の実装を開発者に任せます。
______________
| |
_________| Notification |
| | Mechanism |
| |______________|
|Notif. ^
|Protocol |
| ___|______ _____________
| | LEMONADE | | | _____
__v__ IMAP | MEM | IMAP |NON-LEMONADE | ESMTP | |
| |<--------->|Enabler |<------>|IMAP |<----->| MTA |
| MUA |\ ME-2a | Server | |Store | |_____|
|_____| \ |__________| |_____________|
\ |
\ |URLAUTH
\SUBMIT |
\ ____v_____ _____________
\ | | | | _____
\ | LEMONADE | SUBMIT |NON-LEMONADE | ESMTP | |
-->| MEM | |Submit | | |
| Enabler |------->|Server |------>| MTA |
ME-2b | Server | | | |_____|
|__________| |_____________|
Figure 4: Architecture to Support Non-LEMONADE IMAP Servers with a LEMONADE Realization of an OMA MEM Enabler
図4：OMA MEMイネーブラーのレモネード実現で非レモネードIMAPサーバーをサポートするアーキテクチャ
Figure 5 illustrates the cases where the message store and submit servers are not IMAP store or submit servers. They may be Post Office Protocol (POP3) servers or other proprietary message stores.
図5は、メッセージストアと送信サーバーがサーバーをIMAPストアまたは送信しない場合を示しています。それらは、郵便局プロトコル（POP3）サーバーまたはその他の独自のメッセージストアである場合があります。
______________
| |
_________| Notification |
| | Mechanism |
| |______________|
|Notif. ^
|Protocol |
| ___|______ _____________
| | LEMONADE | | | _____
__v__ IMAP | MEM | I2 |Proprietary | ESMTP | |
| |<--------->|Enabler |<------>|Message |<----->| MTA |
| MUA |\ ME-2a | Server | |Store | |_____|
|_____| \ |__________| |_____________|
\ |
\ |URLAUTH
\SUBMIT |
\ ____v_____ _____________
\ | | | | _____
\ | LEMONADE | I2 |Proprietary | ESMTP | |
-->| MEM | |Submit | | |
| Enabler |------->|Server |------>| MTA |
ME-2b | Server | | | |_____|
|__________| |_____________|
Figure 5: Architecture to Support Non-IMAP Servers with a LEMONADE Realization of OMA MEM Enabler
図5：OMA MEM Enablerのレモネード実現でIMAP以外のサーバーをサポートするアーキテクチャ
I2 designates proprietary adapters to the backends.
I2は、独自のアダプターをバックエンドに指定します。
OMA MEM Requirements [MEM-req] and Architecture [MEM-arch] emphasize the need to provide mechanisms for server-to-client notifications of email events and filtering. Figure 6 illustrates how notification and filtering works in the LEMONADE profile [PROFILE].
OMA MEM要件[MEM-REQ]およびアーキテクチャ[MEM-ARCH]は、メールイベントとフィルタリングのサーバーからクライアント通知のメカニズムを提供する必要性を強調しています。図6は、通知とフィルタリングがレモネードプロファイルでどのように機能するかを示しています[プロファイル]。
______________
| |
_________| Notification |
| | Mechanism |
| |______________|
|Notif. ^
|Protocol -------\ _|__
| ______| ___\>|NF|____
| | | ---- | _____
__v__| IMAP |__ LEMONADE |___ ESMTP __| |
| |<-------->|VF| IMAP |DF |<--------|AF| MTA |
| MUA |\ ME-2a |-- Store |--- --|_____|
|_____| \ |_____________| ^
\_\_______________|_______|
\ |URLAUTH
\SUBMIT |
\ ____v_____
\ | | _____
\ | LEMONADE | ESMTP | |
---->| Submit |--------------->| MTA |
ME-2b | Server | |_____|
|__________|
Figure 6: Filtering Mechanism Defined in LEMONADE Architecture
図6：レモネードアーキテクチャで定義されているフィルタリングメカニズム
In Figure 6, we define four categories of filters:
図6では、4つのカテゴリのフィルターを定義します。
o AF: Administrative Filters - The email service provider usually sets administrative filters. The user typically does not configure AF. AF applies policies covering content filtering, virus protection, spam filtering, etc.
o AF：管理フィルター - メールサービスプロバイダーは通常、管理フィルターを設定します。通常、ユーザーはAFを構成しません。AFは、コンテンツフィルタリング、ウイルス保護、スパムフィルタリングなどをカバーするポリシーを適用します。
o DF: Deposit Filters - Filters that are executed on deposit of new emails. They can be defined as SIEVE filters [SIEVE]. They can include vacation notices [RFC5230]. As SIEVE filters, one can administer them using the SIEVE management protocol [MANAGESIEVE].
o DF：デポジットフィルター - 新しい電子メールの入金時に実行されるフィルター。それらは、ふるいフィルター[ふるい]として定義できます。休暇通知[RFC5230]を含めることができます。ふるいフィルターとして、ふるい管理プロトコル[ManagESIEVE]を使用してそれらを管理できます。
o VF: View Filters - Filters that define which emails are visible to the MUA. View filters can be performed via IMAP using the facilities described in [NOTIFICATIONS].
o VF：ビューフィルター - どのメールがMUAに表示されるかを定義するフィルター。[通知]に記載されている機能を使用して、IMAPを介してビューフィルターを実行できます。
o NF: Notification Filters - Filters that define for what email server event an out-of-band notification is sent to the client, as described in [NOTIFICATIONS].
o NF：通知フィルター - [通知]で説明されているように、クライアントに送信されるメールサーバーイベントの電子メールサーバーイベントを定義するフィルター。
Refer to the aforementioned references for implementation and management of the respective filters.
それぞれのフィルターの実装と管理のための前述の参照を参照してください。
We note there are security risks associated with:
に関連するセキュリティリスクがあることに注意してください。
o Out-of-band notifications
o 帯域外通知
o Server configuration by client
o クライアントによるサーバー構成
o Client configuration by server
o サーバーによるクライアント構成
o Presence of MEM proxy servers
o MEMプロキシサーバーの存在
o Presence of MEM servers as intermediaries
o 仲介業者としてのMEMサーバーの存在
o Measures to address the need to traverse firewalls
o ファイアウォールを通過する必要性に対処するための措置
We refer the reader to the relevant Internet Mail, IMAP, SUBMIT, and Lemonade documents for how we address these issues.
これらの問題に対処する方法については、関連するインターネットメール、IMAP、送信、およびレモネードドキュメントを読者に紹介します。
The authors acknowledge and appreciate the work and comments of the IETF LEMONADE working group and the OMA MEM working group. We extracted the contents of this document from sections of [PROFILE-bis] by Stephane Maes, Alexey Melnikov, and Dave Cridland, as well as sections of [NOTIFICATIONS] by Stephane Maes and Ray Cromwell.
著者は、IETFレモネードワーキンググループとOMA MEMワーキンググループの作業とコメントを認め、感謝しています。このドキュメントの内容は、ステファン・メイズ、アレクセイ・メルニコフ、デイブ・クライドランドによる[プロファイルビス]のセクションから、およびステファン・メイズとレイ・クロムウェルによる[通知]のセクションから抽出しました。
[EMAIL] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.
[電子メール] Klensin、J。、「Simple Mail Transfer Protocol」、RFC 5321、2008年10月。
[MAIL] Crocker, D., "Internet Mail Architecture", Work in Progress, October 2008.
[メール] Crocker、D。、「インターネットメールアーキテクチャ」、2008年10月、進行中の作業。
[MANAGESIEVE] Melnikov, A. and T. Martin, "A Protocol for Remotely Managing Sieve Scripts", Work in Progress, January 2009.
[ManageSieve] Melnikov、A。およびT. Martin、「Sieve Scriptsをリモートで管理するためのプロトコル」、2009年1月の作業。
[MEM-arch] Open Mobile Alliance, "Mobile Email Architecture Document", OMA, http://member.openmobilealliance.org/ftp/ public_documents/mwg/MEM/Permanent_documents/ OMA-AD-Mobile_Email-V1_0_0-20070614-D.zip, June 2007.
[Mem-Arch]オープンモバイルアライアンス、「モバイルメールアーキテクチャドキュメント」、OMA、http：//member.openmobilealliance.org/ftp/ public_documents/mwg/mem/permanent_documents/oma-ad-mobile_email-v1_0_0-20070614-d。ZIP、2007年6月。
[MEM-req] Open Mobile Alliance, "Mobile Email Requirements Document", OMA, http://www.openmobilealliance.org/, Oct 2005.
[Mem-Req] Open Mobile Alliance、「Mobile Email Recomations Document」、OMA、http：//www.openmobilealliance.org/、2005年10月。
[MEM-ts] Open Mobile Alliance, "Mobile Email Technical Specification", OMA, Work in Progress, http://www.openmobilealliance.org/, Oct 2007.
[MEM-TS]オープンモバイルアライアンス、「モバイルメールテクニカル仕様」、OMA、Work in Progress、http：//www.openmobilealliance.org/、2007年10月。
[NOTIFICATIONS] Gellens, R. and S. Maes, "Lemonade Notifications Architecture", Work in Progress, July 2008.
[通知] Gellens、R。およびS. Maes、「レモネード通知アーキテクチャ」、2008年7月の作業。
[PROFILE] Maes, S. and A. Melnikov, "Internet Email to Support Diverse Service Environments (Lemonade) Profile", RFC 4550, June 2006.
[プロファイル] Maes、S。およびA. Melnikov、「多様なサービス環境（レモネード）プロファイルをサポートするインターネットメール」、RFC 4550、2006年6月。
[PROFILE-bis] Cridland, D., Melnikov, A., and S. Maes, "The Lemonade Profile", Work in Progress, September 2008.
[Profile-bis] Cridland、D.、Melnikov、A。、およびS. Maes、「The Lemonade Profile」、2008年9月、進行中の作業。
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[RFC3501] CRISPIN、M。、「インターネットメッセージアクセスプロトコル - バージョン4REV1」、RFC 3501、2003年3月。
[RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail", RFC 4409, April 2006.
[RFC4409] Gellens、R。およびJ. Klensin、「Message Submission for Mail」、RFC 4409、2006年4月。
[RFC5230] Showalter, T. and N. Freed, "Sieve Email Filtering: Vacation Extension", RFC 5230, January 2008.
[RFC5230] Showalter、T。and N. Freed、「Sieve Emailフィルタリング：休暇拡張」、RFC 5230、2008年1月。
[SIEVE] Guenther, P. and T. Showalter, "Seive: An Email Filtering Language", RFC 5228, January 2008.
[Sieve] Guenther、P。and T. Showalter、「Seive：An Emailフィルタリング言語」、RFC 5228、2008年1月。
Authors' Addresses
著者のアドレス
Eric W. Burger Consultant New Hampshire USA
エリック・W・バーガーコンサルタントニューハンプシャーUSA
Phone:
Fax: +1 530-267-7447
EMail: eburger@standardstrack.com
URI: http://www.standardstrack.com
Glenn Parsons Nortel Networks 3500 Carling Avenue Ottawa, ON K2H 8E9 Canada
グレンパーソンズノーテルネットワーク3500カーリングアベニューオタワ、K2H 8E9カナダ
Phone: +1 613 763 7582
EMail: gparsons@nortel.com