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
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.
著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
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.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版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.
インターネットメールプロトコルを使用して、オープン・モバイル・アライアンス（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）のアーキテクチャについて説明します。 LEMONADEワーキンググループは、モバイル環境での使用のためにこれらのプロトコルの多くを強化しました。レモネードプロフィール[PROFILE]およびその改正、[PROFILEビス]、そのようなプロトコルおよびプロトコルの使用を要約します。この文書は、OMA MEM要件文書[MEM-REQ]は、OMA MEMアーキテクチャ[MEM-アーチ]、および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 LEMONADEは、それらと連携しており、その入力上のインターネットメール拡張機能の多くをベースとしています。このセクションでは、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.
OMAモバイルメールイネーブラのクライアント側の機能を実装MEMクライアントO。また、ユーザーに携帯メールのユーザーエクスペリエンスとインターフェイスを提供し、接続されていないときMEMサーバーに送信される電子メールやデータを格納するための責任があります。
o The MEM server that implements the server-side functionality of the OMA Mobile Email (MEM) enabler.
OMAモバイルメール（MEM）イネーブラのサーバ側機能を実装MEMサーバO。
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.
MEMクライアントとMEMサーバ間のMEMプロトコルO。これは、電子メールサーバの変更と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:
直接モバイルメールイネーブラをサポートするために必要なその他OMAイネーブラーO。彼らは、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.
ME-1 O：MEMサーバとMEMプロトコルを介して相互作用するMEMクライアント・インターフェース。
o ME-2: Corresponding interface of the MEM server.
ME-2 O：MEMサーバーの対応するインターフェース。
o ME-3: Out-of-band MEM server interfaces; for example, to support generation of server-to-client notifications.
ME-3 O：アウトオブバンドMEMサーバインターフェース;例えば、サーバーからクライアントへの通知の生成をサポートします。
o ME-4: Out-of-band MEM client interfaces (e.g., to receive server-to-client notifications).
ME-4 O：アウトオブバンドMEMクライアント・インターフェース（例えば、サーバからクライアントへの通知を受信します）。
o ME-5: Interface for management of MEM enabler server settings, user preferences, and filters, globally and per account.
O ME-5：MEMのイネーブラーサーバーの設定、ユーザー設定、およびフィルタ、グローバルおよびアカウントごとの管理のためのインターフェイス。
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-アーチ】さらなる展開モデルを識別します。
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-アーチ]は、ファイアウォールトラバーサルを容易にするために、ファイアウォールの先に展開することができるサーバコンポーネントとして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.
MEMクライアントや他のイネーブラは、携帯電話事業者のドメイン内にあるO、そこ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.
MEMクライアントや他のイネーブラは、携帯電話事業者のドメイン内にあるO、MEMプロキシは、サードパーティのサービスプロバイダのドメインであり、そしてMEMサーバやメールサーバがメールサービスプロバイダのドメイン内にあります。
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.
MEMクライアント、他のイネーブラ、およびMEMサーバoをモバイルオペレータドメインであり、電子メールサーバは、メールサービスプロバイダのドメインです。
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.
MEMクライアントや他のイネーブラは、携帯電話事業者のドメイン内にあるO、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レモネード活性はレモネードプロフィールを由来している[PROFILEビス]矢印はコンテンツの流れを示す図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:
レモネードプロフィール[PROFILE]は前提としています。
o IMAP protocol [RFC3501], including LEMONADE profile extensions [PROFILE].
レモネードプロフィール拡張[PROFILE]を含むO IMAPプロトコル[RFC3501]。
o SUBMIT protocol [RFC4409], including LEMONADE profile extensions.
Oレモネードプロファイル拡張などのプロトコル[使いrfc4409]を、SUBMIT。
o LEMONADE profile compliant IMAP store connected to an MTA (Mail Transfer Agent) via the ESMTP [EMAIL].
ESMTP [EMAIL]を介してMTA（メール転送エージェント）に接続されたOレモネードプロフィール準拠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 LEMONADE対応のMUA（メールユーザエージェント）。アウト・オブ・バンド通知の使用はレモネードプロフィールに記載されているが、基礎をなす通知メカニズム/プロトコルのサポートは、レモネード仕様の範囲外です。
Further details on the IETF email protocol stack and architecture can be found in [MAIL].
IETFメールプロトコルスタックアーキテクチャの詳細は[MAIL]に見出すことができます。
3.1. Relationship between the OMA MEM and LEMONADE Logical Architectures
3.1. OMA MEMとレモネード論理アーキテクチャーの関係
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ストアとSUBMITサーバーを拡張しているので、レモネードプロファイルが提供する電子メールのモバイル有効化は、直接これらのサーバーで提供されています。みなされ、レモネードプロファイルで指定された場合のOMA MEM論理アーキテクチャへのマッピングは、我々は論理的にMEMサーバやメールサーバを兼ね備えています。しかし、LEMONADEに我々は論理的に異なるレモネードメッセージストアとレモネードSUBMITサーバーにそれらを分割します。 ME-2は、2つのインターフェースから構成されています。 ME-2aはレモネードプロファイルに従って拡張IMAPあります。 ME-2bはレモネードプロファイルに従って拡張SUBMITれます。
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イネーブラの一部です。
3.2. LEMONADE Realization of OMA MEM with non-LEMONADE-Compliant Servers
3.2. 非LEMONADE準拠サーバーとOMA MEMのレモネード実現
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サーバコンポーネント間I2インターフェースとIMAPストアとSUBMITサーバは、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.
模式的な性質のものであり、実際の実装を規定していないの実現に注意することが重要です。例えば、一方がレモネードMEMイネーブラサーバと実装の単一のインスタンスで、図4に示す送信サーバを共存さ想像できました。同様に、我々は意識的にIMAPプロキシやIMAPバックツーバックユーザエージェントでもないようLEMONADE MEMイネーブラにラベルを付けます。 LEMONADEは、開発者への実際の実装を残します。
______________
| |
_________| 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
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イネーブラのレモネード実現と非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-アーチ]は、電子メールイベントやフィルタリングのサーバーからクライアントへ通知するためのメカニズムを提供する必要性を強調する。図6は、通知及びフィルタリングがレモネードプロフィール[PROFILE]でどのように動作するかを示しています。
______________
| |
_________| 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.
AF O：管理フィルタ - メールサービスプロバイダは、通常、管理者のフィルタを設定します。ユーザーは、一般的に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：預金フィルタ - 新しい電子メールの預金上で実行されているフィルタ。彼らは、SIEVEフィルタ[SIEVE]として定義することができます。彼らは休暇のお知らせ[RFC5230]を含めることができます。 SIEVEフィルタとして、一つはSIEVE管理プロトコル[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に表示されている定義フィルタが。ビューフィルタは、[NOTIFICATIONS]で説明した機能を使用して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：通知フィルタ - [NOTIFICATIONS]で説明したように、アウトオブバンド通知は、クライアントに送信されたものを電子メールサーバのイベントに対して定義フィルタ。
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 Serverの構成
o Client configuration by server
サーバによるoクライアントの設定
o Presence of MEM proxy servers
OプレゼンスMEMのプロキシサーバ
o Presence of MEM servers as intermediaries
仲介としてMEMサーバの存在O
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、SUBMIT、およびレモネード文書に読者を参照してください。
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ワーキンググループのコメントを感謝しています。我々は、[PROFILEビス]ステファンマース、アレクセイメルニコフ、とDave Cridland、ならびにステファンマースとレイ・クロムウェルによって[NOTIFICATIONS]のセクションによってのセクションからこの文書の内容を抽出しました。
[EMAIL] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.
[EMAIL] Klensin、J.、 "簡易メール転送プロトコル"、RFC 5321、2008年10月。
[MAIL] Crocker, D., "Internet Mail Architecture", Work in Progress, October 2008.
[MAIL]クロッカー、D.、 "インターネットメールのアーキテクチャ"、進歩、2008年10月の作業。
[MANAGESIEVE] Melnikov, A. and T. Martin, "A Protocol for Remotely Managing Sieve Scripts", Work in Progress, January 2009.
[MANAGESIEVE]メルニコフ、A.およびT.マーティン、「リモート管理Sieveスクリプトのための議定書」、進歩、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-アーチ]オープン・モバイル・アライアンス、 "携帯メールアーキテクチャ文書"、OMA、http://member.openmobilealliance.org/ftp/ public_documents / MWG / MEM / Permanent_documents / OMA-AD-Mobile_Email-V1_0_0-20070614-D。ジップ、2007年6月。
[MEM-req] Open Mobile Alliance, "Mobile Email Requirements Document", OMA, http://www.openmobilealliance.org/, Oct 2005.
[MEM-REQ]オープン・モバイル・アライアンス、 "モバイルメール要件文書"、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、進捗状況、http://www.openmobilealliance.org/、2007年10月での作業。
[NOTIFICATIONS] Gellens, R. and S. Maes, "Lemonade Notifications Architecture", Work in Progress, July 2008.
[NOTIFICATIONS] Gellens、R.とS.マース、 "レモネード通知アーキテクチャ"、進歩、2008年7月に作業。
[PROFILE] Maes, S. and A. Melnikov, "Internet Email to Support Diverse Service Environments (Lemonade) Profile", RFC 4550, June 2006.
、RFC 4550、2006年6月 "多様なサービス環境（レモネード）プロファイルをサポートするインターネット電子メール" [PROFILE]マース、S.およびA.メルニコフ、。
[PROFILE-bis] Cridland, D., Melnikov, A., and S. Maes, "The Lemonade Profile", Work in Progress, September 2008.
[PROFILEビス] Cridland、D.、メルニコフ、A.、およびS.マース、 "レモネードプロファイル"、進歩、2008年9月の作業。
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[RFC3501]のCrispin、M.、 "インターネットメッセージアクセスプロトコル - VERSION 4rev1"、RFC 3501、2003年3月。
[RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail", RFC 4409, April 2006.
[RFC4409] Gellens、R.とJ. Klensin、 "メールのメッセージの提出"、RFC 4409、2006年4月。
[RFC5230] Showalter, T. and N. Freed, "Sieve Email Filtering: Vacation Extension", RFC 5230, January 2008.
[RFC5230]ショーウォルター監督、T.およびN.フリード、 "ふるいメールフィルタリング：休暇延長"、RFC 5230、2008年1月。
[SIEVE] Guenther, P. and T. Showalter, "Seive: An Email Filtering Language", RFC 5228, January 2008.
[SIEVE]ギュンター、P.およびT.ショーウォルター監督、 "Seive：メールフィルタリング言語"、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
電話：ファックス：+1 530-267-7447電子メール：eburger@standardstrack.com URI：http://www.standardstrack.com
Glenn Parsons Nortel Networks 3500 Carling Avenue Ottawa, ON K2H 8E9 Canada
グレン・パーソンズノーテルネットワークK2H 8E9カナダON 3500カーリングアベニューオタワ、
Phone: +1 613 763 7582 EMail: gparsons@nortel.com
電話：+1 613 763 7582 Eメール：gparsons@nortel.com