RFC1733 日本語訳

1733 Distributed Electronic Mail Models in IMAP4. M. Crispin. December 1994. (Format: TXT=6205 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文

Network Working Group                                         M. Crispin
Request for Comments: 1733                      University of Washington
Category: Informational                                    December 1994

コメントを求めるワーキンググループM.クリスピン要求をネットワークでつないでください: 1733年のワシントン大学カテゴリ: 情報の1994年12月

              DISTRIBUTED ELECTRONIC MAIL MODELS IN IMAP4

IMAP4の分配された電子メールモデル

Status of this Memo

このMemoの状態

   This memo provides information for the Internet community.  This memo
   does not specify an Internet standard of any kind.  Distribution of
   this memo is unlimited.

このメモはインターネットコミュニティのための情報を提供します。 このメモはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。

Distributed Electronic Mail Models

分配された電子メールモデル

   There are three fundamental models of client/server email: offline,
   online, and disconnected use.  IMAP4 can be used in any one of these
   three models.

クライアント/サーバメールの3つの基本的なモデルがあります: オフラインの、そして、オンラインの、そして、切断している使用。 これらの3つのモデルのいずれでもIMAP4を使用できます。

   The offline model is the most familiar form of client/server email
   today, and is used by protocols such as POP-3 (RFC 1225) and UUCP.
   In this model, a client application periodically connects to a
   server.  It downloads all the pending messages to the client machine
   and deletes these from the server.  Thereafter, all mail processing
   is local to the client.  This model is store-and-forward; it moves
   mail on demand from an intermediate server (maildrop) to a single
   destination machine.

オフラインモデルは、今日最も身近なフォームのクライアント/サーバメールであり、POP-3(RFC1225)やUUCPなどのプロトコルによって使用されます。 このモデルでは、クライアントアプリケーションは定期的にサーバに接続します。それは、すべての未定のメッセージをクライアントマシンにダウンロードして、サーバからこれらを削除します。クライアントにとって、その後、すべてのメール処理が地方です。 このモデルは、店とフォワードです。 それはオンデマンドの中間的サーバ(郵便受け)から単一の目的地マシンまでのメールを動かします。

   The online model is most commonly used with remote filesystem
   protocols such as NFS.  In this model, a client application
   manipulates mailbox data on a server machine.  A connection to the
   server is maintained throughout the session.  No mailbox data are
   kept on the client; the client retrieves data from the server as is
   needed.  IMAP4 introduces a form of the online model that requires
   considerably less network bandwidth than a remote filesystem
   protocol, and provides the opportunity for using the server for CPU
   or I/O intensive functions such as parsing and searching.

オンラインモデルはNFSなどの遠隔ファイルシステムプロトコルと共に最も一般的に使用されます。 このモデルでは、クライアントアプリケーションはサーバマシンに関するメールボックスデータを操ります。 サーバとの接続はセッションの間中維持されます。 メールボックスデータは全くクライアントの上に保たれません。 クライアントはそのままで必要な状態でサーバからのデータを検索します。 IMAP4は遠隔ファイルシステムプロトコルよりかなり少ないネットワーク回線容量を必要とするオンラインモデルのフォームを導入して、CPUにサーバを使用する機会か構文解析や探すことなどの入出力の徹底的な機能を提供します。

   The disconnected use model is a hybrid of the offline and online
   models, and is used by protocols such as PCMAIL (RFC 1056).  In this
   model, a client user downloads some set of messages from the server,
   manipulates them offline, then at some later time uploads the
   changes.  The server remains the authoritative repository of the
   messages.  The problems of synchronization (particularly when
   multiple clients are involved) are handled through the means of
   unique identifiers for each message.

使用がモデル化する切断することは、オフラインの、そして、オンラインのモデルの混血であり、PCMAIL(RFC1056)などのプロトコルによって使用されます。 このモデルでは、クライアントユーザは、サーバから何らかのセットのメッセージをダウンロードして、それらをオフラインで操って、次に、何らかの後の時間に変化をアップロードします。 サーバはメッセージの正式の倉庫のままで残っています。 同期(特に複数のクライアントがかかわるとき)の問題は各メッセージのためのユニークな識別子によって扱われます。

Crispin                                                         [Page 1]

RFC 1733                     IMAP4 - Model                 December 1994

クリスピン[1ページ]RFC1733IMAP4--モデル1994年12月

   Each of these models have their own strengths and weaknesses:

これらのモデル各人には、それら自身の長所と短所があります:

      Feature                               Offline Online  Disc
      -------                               ------- ------  ----
      Can use multiple clients               NO      YES     YES
      Minimum use of server connect time     YES     NO      YES
      Minimum use of server resources        YES     NO      NO
      Minimum use of client disk resources   NO      YES     NO
      Multiple remote mailboxes              NO      YES     YES
      Fast startup                           NO      YES     NO
      Mail processing when not online        YES     NO      YES

オフラインオンラインディスクを特集してください。------- ------- ------ ---- はいのはいの複数のクライアントノーMinimumが使用するクライアントディスクリソースいいえはいのMultipleリモートなメールボックスいいえはいのはいFastのサーバリソースはいいいえいいえMinimum使用のサーバ接続時間のはいいいえはいMinimum使用の缶の使用、オンラインはいいいえはいときの始動いいえはいいいえメール処理

   Although IMAP4 has its origins as a protocol designed to accommodate
   the online model, it can support the other two models as well.  This
   makes possible the creation of clients that can be used in any of the
   three models.  For example, a user may wish to switch between the
   online and disconnected models on a regular basis (e.g. owing to
   travel).

IMAP4はオンラインモデルに対応するように設計されたプロトコルとして起源を発しますが、それはまた、他の2つのモデルをサポートできます。 これで、3つのモデルのいずれでも使用できるクライアントの作成は可能になります。 例えば、ユーザは定期的(例えば、旅行のために)にオンラインの、そして、切断しているモデルを切り換えたがっているかもしれません。

   IMAP4 is designed to transmit message data on demand, and to provide
   the facilities necessary for a client to decide what data it needs at
   any particular time.  There is generally no need to do a wholesale
   transfer of an entire mailbox or even of the complete text of a
   message.  This makes a difference in situations where the mailbox is
   large, or when the link to the server is slow.

IMAP4は、オンデマンドのメッセージデータを送って、クライアントが、それが特定の何時でもどんなデータを必要とするかを決めるのに必要な施設を提供するように設計されています。 一般に、全体のメールボックスかメッセージの全文さえの大量の転送をする必要は全くありません。 メールボックスが大きいか、またはサーバへのリンクが遅いときに、これに状況で効果があります。

   More specifically, IMAP4 supports server-based RFC 822 and MIME
   processing.  With this information, it is possible for a client to
   determine in advance whether it wishes to retrieve a particular
   message or part of a message.  For example, a user connected to an
   IMAP4 server via a dialup link can determine that a message has a
   2000 byte text segment and a 40 megabyte video segment, and elect to
   fetch only the text segment.

より明確に、IMAP4は、サーバベースのRFC822とMIMEが処理であるとサポートします。 この情報では、クライアントが、あらかじめそれがメッセージの特定のメッセージか一部を検索したがっているかどうかと決心しているのは、可能です。 例えば、ダイアルアップリンクを通してIMAP4サーバに接続されたユーザは、メッセージには2000年のバイトのテキスト・セグメントと40メガバイトのビデオセグメントがあると決心して、テキスト・セグメントだけをとって来るのを選ぶことができます。

   In IMAP4, the client/server relationship lasts only for the duration
   of the TCP connection.  There is no registration of clients.  Except
   for any unique identifiers used in disconnected use operation, the
   client initially has no knowledge of mailbox state and learns it from
   the IMAP4 server when a mailbox is selected.  This initial transfer
   is minimal; the client requests additional state data as it needs.

IMAP4では、クライアント/サーバ関係はTCP接続の持続時間のためだけに持続します。 クライアントの登録が全くありません。 切断している使用で使用されるどんなユニークな識別子を除いても、操作、クライアントは、初めは、メールボックス状態に関する知識を全く持たないで、メールボックスが選択されるとき、IMAP4サーバからそれを学びます。 この初期の転送は最小限です。 クライアントはそれとしてのデータが必要とする追加状態を要求します。

   As noted above, the choice for the location of mailbox data depends
   upon the model chosen.  The location of message state (e.g. whether
   or not a message has been read or answered) is also determined by the
   model, and is not necessarily the same as the location of the mailbox
   data.  For example, in the online model message state can be co-
   located with mailbox data; it can also be located elsewhere (on the
   client or on a third agent) using unique identifiers to achieve

上で述べたように、メールボックスデータの位置のための選択は選ばれたモデルに頼っています。 メッセージ状態の位置は、また、モデルが決定されて(例えば、メッセージは、読まれたか、または答えられたかどうか)、必ずメールボックスデータの位置と同じであるというわけではありません。 例えば、オンラインモデルでは、メッセージ状態はメールボックスデータで共同位置できます。 また、それは、ほかの場所(クライアントか3番目のエージェントに関して)に達成するユニークな識別子を使用することで位置できます。

Crispin                                                         [Page 2]

RFC 1733                     IMAP4 - Model                 December 1994

クリスピン[2ページ]RFC1733IMAP4--モデル1994年12月

   common reference across sessions.  The latter is particularly useful
   with a server that exports public data such as netnews and does not
   maintain per-user state.

セッションの向こう側の共通参照。 後者はネットニュースなどの公衆データをエクスポートして、1ユーザあたりの状態を維持しないサーバによって特に役に立ちます。

   The IMAP4 protocol provides the generality to implement these
   different models.  This is done by means of server and (especially)
   client configuration, and not by requiring changes to the protocol or
   the implementation of the protocol.

IMAP4プロトコルは、これらが異なったモデルであると実装するために一般性を提供します。 プロトコルのプロトコルか実装への変化を必要とするのではなく、サーバと(特に)クライアント構成によってこれをします。

Security Considerations

セキュリティ問題

   Security issues are not discussed in this memo.

このメモで安全保障問題について議論しません。

Author's Address:

作者のアドレス:

   Mark R. Crispin
   Networks and Distributed Computing, JE-30
   University of Washington
   Seattle, WA  98195

ワシントン マークR.クリスピンネットワークと分散コンピューティング、JE-30ワシントン大学シアトル、98195

   Phone: (206) 543-5762

以下に電話をしてください。 (206) 543-5762

   EMail: MRC@CAC.Washington.EDU

メール: MRC@CAC.Washington.EDU

Crispin                                                         [Page 3]

クリスピン[3ページ]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

location.host

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る