RFC984 日本語訳
0984 PCMAIL: A distributed mail system for personal computers. D.D.Clark, M.L. Lambert. May 1986. (Format: TXT=69333 bytes) (Obsoleted by RFC0993) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group David D. Clark
Request for Comments: 984 Mark L. Lambert
M. I. T. Laboratory for Computer Science
May 1986
コメントを求めるワーキンググループデヴィッドD.クラークの要求をネットワークでつないでください: 984 マークL.ランバートM.I.T.コンピュータ科学研究所1986年5月
PCMAIL: A Distributed Mail System for Personal Computers
PCMAIL: パーソナルコンピュータの分配されたメールシステム
1. Status of this Document
1. このDocumentの状態
This document is a preliminary discussion of the design of a personal-computer-based distributed mail system. It is published for discussion and comment, and does not constitute a standard. As the proposal may change, implementation of this document is not advised. Distribution of this memo is unlimited.
このドキュメントは個人的なコンピュータベースの分配されたメールシステムの設計の予備的な討論です。 それは、議論とコメントのために発行されて、規格を構成しません。 提案が変化するとき、このドキュメントの実装は教えられません。 このメモの分配は無制限です。
2. Introduction
2. 序論
Pcmail is a distributed mail system that provides mail service to an arbitrary number of users, each of which owns one or more personal computers (PCs). The system is divided into two halves. The first consists of a single entity called the "repository". The repository is a storage center for incoming mail. Mail for a Pcmail user can arrive externally from the Internet or internally from other repository users. The repository also maintains a stable copy of each user's mail state (this will hereafter be referred to as the user's "global mail state"). The repository is therefore typically a computer with a large amount of disk storage.
Pcmailはそれのそれぞれが1台以上のパーソナルコンピュータ(PC)を所有しているユーザの特殊活字の数字に対するメールサービスを提供する分配されたメールシステムです。 システムは2つの半分に分割されます。 1番目は「倉庫」と呼ばれる単一体から成ります。 倉庫は入って来るメールのためのストレージセンターです。 Pcmailユーザのためのメールはインターネットから他の倉庫ユーザから外部的に内部的に到着できます。 また、倉庫は安定したコピーの各ユーザのメール状態を維持します(これは今後ユーザの「グローバルなメール状態」と呼ばれるでしょう)。 したがって、通常、倉庫は多量のディスクストレージがあるコンピュータです。
The second half of Pcmail consists of one or more "clients". Each Pcmail user may have an arbitrary number of clients, which are typically PCs. The clients provide a user with a friendly means of accessing the user's global mail state over a network. In order to make the interaction between the repository and a user's clients more efficient, each client maintains a local copy of its user's global mail state, called the "local mail state". Since clients are PCs, they may not always have access to a network (and therefore to the global mail state in the repository). This means that the local and global mail states may not be identical all the time, making synchronization between local and global mail states necessary.
Pcmailの後半は1「クライアント」から成ります。 それぞれのPcmailユーザには、クライアントの特殊活字の数字があるかもしれません(通常、PCです)。 クライアントはネットワークの上でユーザのグローバルなメール状態にアクセスする好意的な手段をユーザに提供します。 倉庫とユーザのクライアントとの相互作用をより効率的にするように、「地方のメール状態」は、各クライアントが地方のコピーのユーザのグローバルなメール状態を維持すると呼びました。 クライアントがPCであるので、それらはいつも、ネットワーク(そしてしたがって、倉庫のグローバルなメール状態に)に近づく手段を持っているかもしれないというわけではありません。 これは、地方の、そして、グローバルなメール州が絶えず同じでないかもしれないことを意味します、地方の、そして、グローバルなメール州の間の同期を必要にして。
Clients communicate with the repository via the Distributed Mail
System Protocol (DMSP); the specification for this protocol appears
in appendix A. The repository is therefore a DMSP server in addition
to a mail end-site and storage facility. DMSP provides a complete
set of mail manipulation operations ("send a message", "delete a
message", "print a message", etc.). DMSP also provides special
operations to allow easy synchronization between a user's global mail
state and his clients' local mail states. Particular attention has
been paid to the way in which DMSP operations act on a user's mail
state. All DMSP operations are atomic (that is, they are guaranteed
DistributedメールSystemプロトコル(DMSP)でクライアントは倉庫で交信します。 このプロトコルのための仕様は付録A.に載っています。したがって、倉庫はメール端サイトと貯蔵場所に加えてDMSPサーバです。 DMSPはメールの完全な操作操作(「メッセージを送っ」て、「メッセージを削除し」て、「メッセージを印刷しますなど」)を提供します。 また、DMSPは、ユーザのグローバルなメール州と彼のクライアントの地方のメール州の間の簡単な同期を許容するために特殊作戦を提供します。 DMSP操作がユーザのメール状態に影響する方法に特別の注意を向けました。 すべてのDMSP操作が原子です。(それがそう、それらは保証されます。
Clark & Lambert [Page 1]
クラークとランバート[1ページ]
RFC 984 May 1986 PCMAIL
RFC984 1986年5月のPCMAIL
either to succeed completely, or fail completely). A client can be abruptly disconnected from the repository without leaving inconsistent or damaged mail states.
完全に成功するか、または完全に失敗するどちらか) 矛盾したか破損しているメールを州に残さないで、倉庫からクライアントから突然に切断することができます。
Pcmail is a mail system for PCs. Its design has therefore been heavily influenced by several characteristics unique to PCs. First, PCs are relatively inexpensive. This means that people may own more than one PC, perhaps putting one in an office and one at home. Second, PCs are portable. Most PCs can be packed up and moved in the back seat of an automobile, and a few are truly portable--about the size of a briefcase--and battery-powered. Finally, PCs are resource-poor. A typical PC has a small amount (typically less than one megabyte) of main memory and little in the way of mass storage (floppy-disk drives that can access perhaps 360 kilobytes of data).
PcmailはPCのメールシステムです。 したがって、デザインはPCにユニークないくつかの特性によって大いに影響を及ぼされました。 まず最初に、PCは比較的安価です。 恐らくオフィスとホームの1つに1を入れて、これは、人々が1台以上のPCを所有するかもしれないことを意味します。 2番目に、PCは携帯用です。 本当に、いくつかはブリーフケースのサイズに関して携帯用です--自動車の後部座席でほとんどのPCを詰め込んで、動かすことができます、そして、そして、バッテリーによる動力付き。 最終的に、PCは資源の乏しいです。 典型的なPCは主記憶装置に少量(通常1メガバイト未満)少ししか大容量記憶(恐らく360キロバイトのデータにアクセスできるフロッピーディスクドライブ)の方法で持っていません。
Because PCs are relatively inexpensive and people may own more than one, Pcmail has been designed to allow users multiple access points to their mail state. Each Pcmail user can have several client PCs, each of which can access the user's mail by communicating with the repository over a network. The client PCs all maintain local copies of the user's global mail state, and synchronize the local and global states using DMSP.
PCが比較的安価であり、人々が1つ以上を所有するかもしれないので、Pcmailはそれらのメール状態への複数のアクセスポイントをユーザに許容するように設計されています。 それぞれのPcmailユーザはいくつかのクライアントPCを持つことができます。ネットワークの上で倉庫で交信することによって、それはそれぞれユーザのメールにアクセスできます。 クライアントPCは、地方のコピーのユーザのグローバルなメール状態を皆、維持して、DMSPを使用することで地方の、そして、グローバルな州を連動させます。
It is possible, even likely, that many PCs will only infrequently be connected to a network (and thus be able to communicate with the repository). The Pcmail design therefore allows two modes of communication between repository and client. "Interactive mode" is used when the client PC is always connected to the network. Any changes to the client's local mail state are immediately also made to the repository's global mail state, and any incoming mail is immediately transmitted from repository to client. "Batch mode" is used by clients that have infrequent access to the repository. Users manipulate the client's local mail state, queueing the changes as "actions". When next connected to the repository, the actions are transmitted, and the client's local mail state is synchronized with the repository's global mail state.
おそらくさえそんなに多くのPCがネットワークにまれに接続されるだけであるのは(その結果、倉庫で交信できてください)、可能です。 したがって、Pcmailデザインは倉庫とクライアントとのコミュニケーションの2つのモードを許容します。 クライアントPCがいつもネットワークに接続されるとき、「会話型」は使用されています。 また、すぐにクライアントの地方のメール状態へのどんな変更も倉庫のグローバルなメール状態にします、そして、すぐに、倉庫からクライアントまでどんな入って来るメールも送ります。 「バッチ・モード」は珍しいアクセスを倉庫に持っているクライアントによって使用されます。 ユーザはクライアントの地方のメール状態を操って、待ち行列は「動作」として変化です。 倉庫に接続されていて、次に、動作が送られて、クライアントの地方のメール状態が倉庫のグローバルなメール状態と同期するとき。
Finally, the Pcmail design minimizes the effect of using a resource-poor PC as a client. Mail messages are split into two parts: a "descriptor" and a "body". The descriptor is a capsule message summary whose length (typically about 100 bytes) is independent of the actual message length. The body is the actual message text, including an RFC-822 standard message header. While the client may not have enough storage to hold a complete set of messages, it can always hold a complete set of descriptors, thus
最終的に、Pcmailデザインはクライアントとして資源の乏しいPCを使用するという効果を最小にします。 メール・メッセージは2つの部品に分けられます: 「記述子」と「ボディー。」 記述子は長さ(通常およそ100バイト)が実際のメッセージ長から独立しているカプセルメッセージ概要です。 ボディーはRFC-822の標準のメッセージヘッダーを含む実際のメッセージ・テキストです。 クライアントには、完全なセットのメッセージを保持できるくらいのストレージがないかもしれませんが、その結果、それはいつも完全なセットの記述子を保持できます。
Clark & Lambert [Page 2]
クラークとランバート[2ページ]
RFC 984 May 1986 PCMAIL
RFC984 1986年5月のPCMAIL
providing the user with at least a summary of his mail state. Message bodies can be pulled over from the repository as client storage becomes available.
少なくとも彼のメール状態の概要をユーザに提供します。 クライアントストレージが利用可能になるのに従って、倉庫からメッセージ本体を引くことができます。
The remainder of this document is broken up into the following sections: first, there is a detailed description of the repository architecture. This is followed by a description of DMSP, its operations, and motivation for its design. A third section describes client architecture. Another section describes a typical DMSP session between the repository and a client. The final section discusses the current Pcmail implementation.
このドキュメントの残りは以下のセクションに終えられます: まず最初に、倉庫アーキテクチャの詳述があります。 デザインに関するDMSPの記述、操作、および動機はこれのあとに続いています。 第3のセクションはクライアントアーキテクチャについて説明します。 もう1つのセクションが倉庫とクライアントとの典型的なDMSPセッションについて説明します。 最終的なセクションは現在のPcmail実装について論じます。
3. Repository Architecture
3. 倉庫アーキテクチャ
A machine running repository code is typically a medium-to-large size computer with a large amount of disk storage. It must also be a permanent network site, since client PCs communicate with the repository over a network, and rely on the repository's being available at any time.
通常、マシン実行倉庫コードは媒体から大判への多量のディスクストレージがあるコンピュータです。 また、それは永久的なネットワークサイトであるに違いありません、クライアントPCがネットワークの上で倉庫で交信して、倉庫のいつでも利用可能な存在に依存するので。
The repository must perform several tasks. First, and most importantly, the repository must efficiently manage a potentially large number of users and their mail states. Mail must be reliably stored in a manner that makes it easy for multiple clients to access the global mail state and synchronize their local mail states with the global state. Second, the repository must be able to communicate efficiently with its clients. The protocol used to communicate between repository and client must be reliable and must provide operations that (1) allow typical mail manipulation, and (2) support Pcmail's distributed nature by allowing efficient synchronization between local and global mail states. Third, the repository must be able to process mail from sources outside the repository's own user community (a primary outside source is the Internet). Internet mail will arrive with a NIC RFC-822 standard message header; the recipient names in the message must be properly translated from the RFC-822 namespace into the repository's namespace.
倉庫はいくつかのタスクを実行しなければなりません。 まず最初に、最も重要に、倉庫は効率的に潜在的に多くのユーザと彼らのメール州を経営しなければなりません。 複数のクライアントがグローバルなメール状態にアクセスして、地元のメール州をグローバルな状態に連動させるのを簡単にする方法でメールを確かに保存しなければなりません。 2番目に、倉庫は効率的にクライアントとコミュニケートできなければなりません。 倉庫とクライアントの間で交信するのに使用されるプロトコルは、信頼できなければならなくて、地方の、そして、グローバルなメール州の間で効率的な同期を許容することによって、典型的なメール操作、および(2)サポートPcmailの分配された本質を(1)が許す操作に提供しなければなりません。 3番目に、倉庫は倉庫の自身のユーザーコミュニティの外のソースからメールを処理できなければなりません(主要な外部の源はインターネットです)。 インターネット・メールはNIC RFC-822の標準のメッセージヘッダーと共に到着するでしょう。 メッセージの受取人名をRFC-822名前空間から倉庫の名前空間に適切に翻訳しなければなりません。
3.1. Management of user mail state
3.1. ユーザメール状態の管理
Pcmail divides the world into a community of users. Each user is
referred to by a user object. A user object consists of a unique
name, a password (which the user's clients use to authenticate
themselves to the repository before manipulating a global mail
state), a list of "client objects" describing those clients
belonging to the user, and a list of "mailbox objects".
Pcmailは世界をユーザの共同体に分割します。 各ユーザはユーザオブジェクトによって言及されます。 ユーザオブジェクトはユニークな名前、パスワード(ユーザのクライアントがグローバルなメール状態を操る前に倉庫に自分たちを認証するのに使用する)、ユーザのものであるそれらのクライアントについて説明する「クライアントオブジェクト」のリスト、および「メールボックスオブジェクト」のリストから成ります。
A client object consists of a unique name and a status. A user
クライアントオブジェクトはユニークな名前と状態から成ります。 ユーザ
Clark & Lambert [Page 3]
クラークとランバート[3ページ]
RFC 984 May 1986 PCMAIL
RFC984 1986年5月のPCMAIL
has one client object for every client he owns; a client cannot
communicate with the repository unless it has a corresponding
client object in a user's client list. Client objects therefore
serve as a means of identifying valid clients to the repository.
Client objects also allow the repository to manage local and
global mail state synchronization; the repository associates with
every global state change a list of client objects corresponding
to those clients which have not recorded the global change
locally.
彼が所有している各クライアントあたり1個のクライアントオブジェクトを持っています。 ユーザの顧客リストに対応するクライアントオブジェクトを持っていない場合、クライアントは倉庫で交信できません。 したがって、クライアントオブジェクトは有効なクライアントを倉庫に特定する手段として機能します。 また、クライアントオブジェクトで、倉庫は地方の、そして、グローバルなメール州の同期を管理できます。 あらゆるグローバルな状態の倉庫関連はそれらのクライアントにとって、対応するクライアントオブジェクトのリストを変えます(局所的にグローバルな変化を記録していません)。
A client's status is either "active" or "inactive". The
repository defines inactive clients as those clients which have
not connected to the repository within a set time period (one week
in the current Pcmail implementation). When an inactive client
does connect to the repository, the repository notifies the client
that it has been "reset". The repository resets a client by
marking all messages in the user's mail state as having changed
since the client last logged in. When the client next
synchronizes with the repository, it will receive a complete copy
of the repository's global mail state. A forced reset is
performed on the assumption that enough global state changes occur
in a week that the client would spend too much time performing an
ordinary local state-global state synchronization.
クライアントの状態は、「アクティブである」か「不活発です」。 倉庫は不活発なクライアントをそれらのクライアントと定義します(セットの期間(現在のPcmail実装における1週間)以内に倉庫に接続しません)。 不活発なクライアントが倉庫に接続するとき、倉庫は、それが「リセットされたこと」をクライアントに通知します。 倉庫は、クライアントが最後にログインして以来変化しているとしてユーザのメール状態のすべてのメッセージをマークすることによって、クライアントをリセットします。 次のクライアントが倉庫に連動すると、それは完本の倉庫のグローバルなメール状態を受けるでしょう。 無理矢理のリセットは十分なグローバルな州の変化がクライアントが普通の地方の州のグローバルな州の同期を実行するのにあまりに多くの時間を費やすだろう1週間後に起こるという前提に実行されます。
Messages are stored in mailboxes. Users can have an arbitrary
number of mailboxes, which serve both to store and to categorize
messages. Since there can be any number of mailboxes, messages
can be categorized to an arbitrarily fine degree. A mailbox
object both names a mailbox and describes its contents. Mailboxes
are identified by a unique name; their contents are described by
three numeric values. The first is the total number of messages
in the mailbox, the second is the total number of unseen messages
(messages that have never been seen by the user via any client) in
the mailbox, and the third is the next available message unique
identifier (UID). This information is stored in the mailbox
object to allow clients to get a summary of a mailbox's contents
without having to read all the messages within the mailbox.
メッセージはメールボックスの中に保存されます。 ユーザはメールボックスの特殊活字の数字を持つことができて、どのサーブをともに保存して、分類したらよいかは通信します。 いろいろなメールボックスがあることができるので、メッセージを任意にすばらしい度合いに分類できます。 メールボックスオブジェクトは、メールボックスを命名して、コンテンツについて説明します。 メールボックスはユニークな名前によって特定されます。 それらの内容は3つの数値によって説明されます。 1番目はメールボックスの中のメッセージの総数です、そして、2番目はメールボックスの中の見えないメッセージ(どんなクライアントを通してもユーザによって一度も見られたことがないメッセージ)の総数です、そして、3番目は次の利用可能なメッセージユニークな識別子(UID)です。 この情報は、クライアントがメールボックスの中にすべてのメッセージを読む必要はなくてメールボックスのコンテンツの概要を得るのを許容するためにメールボックスオブジェクトに保存されます。
Associated with each mailbox are an arbitrary number of message
objects. Each message is broken into two parts--a "descriptor",
which contains a summary of useful information about the message,
and a "body", which is the message text itself, including NIC
RFC-822 message header. Each message is assigned a monotonically
increasing UID based on the owning mailbox's next available UID.
Each mailbox has its own set of UIDs which, together with the
mailbox name and user name, uniquely identify the message within
the repository.
各メールボックスに関連づけられているのは、メッセージオブジェクトの特殊活字の数字です。 2つの部品が各メッセージに細かく分けられます--NIC RFC-822メッセージヘッダーを含むメッセージ・テキスト自体であるメッセージ、および「ボディー」に関する役に立つ情報の概要を含む「記述子。」 所有メールボックスの次の利用可能なUIDに基づく単調に増加するUIDは各メッセージに割り当てられます。 各メールボックスには、それ自身のメールボックス名とユーザ名と共に倉庫の中でメッセージを唯一特定するUIDsのセットがあります。
Clark & Lambert [Page 4]
クラークとランバート[4ページ]
RFC 984 May 1986 PCMAIL
RFC984 1986年5月のPCMAIL
A descriptor holds the following information: the message UID, the
message size in bytes and lines, four "useful" message header
fields (the "date:", "to:", "from:", and "subject:" fields), and
two groups of eight flags each. The first group of flags is
system defined. These flags mark whether the message has never
been seen, whether it has been deleted, whether it is a forwarded
message, and whether the message has been expunged. The remaining
four flags are reserved for future use. The second group of flags
is user defined. The repository never examines these flags
internally; instead they can be used by application programs
running on the clients. Descriptors serve as an efficient means
for clients to get message information without having to waste
time retrieving the message from the repository.
記述子は以下の情報を保持します: メッセージUID、バイトと系列におけるメッセージサイズ、4つの「役に立つ」メッセージヘッダーフィールド(「日付:」 「以下への」「以下」、および「subject:」 分野)、および2つの8人のグループがそれぞれに旗を揚げさせます。 旗の最初のグループは定義されたシステムです。 メッセージが一度も見られたことがないか否かに関係なく、これらはマークに旗を揚げさせます、それが削除されたか否かに関係なく、それが転送されたメッセージであり、メッセージが梢消されたか否かに関係なく。 残っている4個の旗が今後の使用のために予約されます。 旗の2番目のグループは定義されたユーザです。 倉庫はこれらの旗を決して内部的に調べません。 代わりに、クライアントで走るアプリケーション・プログラムはそれらを使用できます。 記述子はクライアントが倉庫からメッセージを検索しながら時間を浪費する必要はなくてメッセージ情報を得る効率的な手段として機能します。
3.2. Repository-to-RFC-822 name translation
3.2. 倉庫からRFC-822への名前翻訳
"Address objects" provide the repository with a means for
translating the RFC-822-style mail addresses in Internet messages
into repository names. The repository provides its own namespace
for message identification. Any message is uniquely identified by
the triple (user-name, mailbox-name, message-UID). Any mailbox is
uniquely identified by the pair (user-name, mailbox-name). Thus
to send a message between two repository users, a user would
address the message to (user-name, mailbox-name). The repository
would deliver the message to the named user and mailbox, and
assign it a UID based on the requested mailbox's next available
UID.
「アドレスオブジェクト」はメールがインターネットメッセージで扱うRFC822スタイルを倉庫名に翻訳するための手段を倉庫に提供します。 倉庫はそれ自身の名前空間をメッセージ識別に提供します。 三重(ユーザ名、メールボックス名、メッセージ-UID)によってどんなメッセージも唯一特定されます。 どんなメールボックスも組(ユーザ名、メールボックス名)によって唯一特定されます。 したがって、2人の倉庫ユーザの間にメッセージを送るために、ユーザは(ユーザ名、メールボックス名)にメッセージを扱うでしょう。 倉庫は、命名されたユーザとメールボックスにメッセージを提供して、要求されたメールボックスの次の利用可能なUIDに基づくUIDをそれに割り当てるでしょう。
In order to translate between RFC-822-style mail addresses and
repository names, the repository maintains a list of address
objects. Each address object is an association between an
RFC-822-style address and a (user-name, mailbox-name) pair. When
mail arrives from the Internet, the repository can use the address
object list to translate the recipients into (user-name,
mailbox-name) pairs and route the message correctly.
メールが扱うRFC822スタイルと倉庫名の間で翻訳するために、倉庫はアドレスオブジェクトのリストを維持します。 それぞれのアドレスオブジェクトはRFC822スタイルアドレスと(ユーザ名、メールボックス名)組との仲間です。 メールがインターネットから到着するとき、倉庫は、(ユーザ名、メールボックス名)組に受取人を翻訳して、正しくメッセージを発送するのにアドレスオブジェクトリストを使用できます。
4. Communication Between Repository and Client: DMSP
4. 倉庫とクライアントとのコミュニケーション: DMSP
The Distributed Mail System Protocol (DMSP) is a block-stream protocol that defines and manipulates the objects mentioned in the previous section. It has been designed to work with Pcmail's single-repository/multiple-client model of the world. In addition to providing typical mail manipulation functions, DMSP provides functions that allow easy synchronization of global and local mail states.
DistributedメールSystemプロトコル(DMSP)は、それが定義する岩塊流プロトコルであり、前項で言及されたオブジェクトを操作します。 それは、Pcmailの世界の複数の単一の倉庫/クライアントモデルと共に働くように設計されています。 典型的なメールマニピュレーション機能を提供することに加えて、DMSPはグローバルで地方のメール州の簡単な同期を許容する機能を提供します。
DMSP is implemented on top of the Unified Stream Protocol (USP),
DMSPはUnified Streamプロトコル(USP)の上で実装されます。
Clark & Lambert [Page 5]
クラークとランバート[5ページ]
RFC 984 May 1986 PCMAIL
RFC984 1986年5月のPCMAIL
specified in MIT-LCS Technical Memo 255. USP provides a reliable
virtual circuit block-stream connection between two machines. USP
defines a basic set of data types ("strings", "integers", "booleans",
etc.). Instances of these data types are grouped in an
application-defined order to form USP blocks. Each USP block is
defined by a numeric "block type"; a USP application can thus
interpret a block's contents based on knowledge of the block's type.
DMSP consists of a set of operations, each of which is comprised of
one or more different USP blocks that are sent between repository and
client.
MIT-LCS Technical Memo255では、指定されています。 USPは2台のマシンの間の頼もしい仮想の回路岩塊流接続を提供します。 USPは基本的なセットのデータ型(「ストリング」、「整数」、「論理演算子」など)を定義します。 これらのデータ型のインスタンスはUSPブロックを形成するアプリケーションで定義された命令で分類されます。 それぞれのUSPブロックは数値「ゴシック体」によって定義されます。 その結果、USPアプリケーションはブロックのタイプに関する知識に基づくブロックのコンテンツを解釈できます。 DMSPは1セットの操作から成ります。それは倉庫とクライアントの間に送られる1つ以上の異なったUSPブロック以上からそれぞれ成ります。
A DMSP session proceeds as follows: a client begins the session with the repository by opening a USP connection to the repository's machine. The client then authenticates both itself and its user to the repository with a "login" operation. If the authentication is successful, the user performs an arbitrary number of DMSP operations before ending the session with a "logout" operation (at which time the connection is closed by the repository).
DMSPセッションは以下の通り続きます: クライアントは、倉庫のマシンにUSP接続を開くことによって、倉庫とのセッションを始めます。 そして、クライアントは「ログイン」操作がある倉庫にそれ自体とそのユーザの両方を認証します。 認証がうまくいくなら、「ログアウトしてください」という操作(接続はどの時に倉庫によって閉店させられるかの)とのセッションを終わらせる前に、ユーザはDMSP操作の特殊活字の数字を実行します。
Because DMSP can manipulate a pair of mail states (local and global) at once, it is extremely important that all DMSP operations are atomic. Failure of any DMSP operation must leave both states in a consistent, known state. For this reason, a DMSP operation is defined to have failed unless an explicit acknowledgement is received by the operation initiator. This acknowledgement can take one of two basic forms, based on two broad categories that all DMSP operations fall into. First, an operation can be a request to perform some mail state modification, in which case the repository will acknowledge the request with either an "ok" or a "failure" (in which case the reason for the failure is also returned). Second, an operation can be a request for information, in which case the request is acknowledged by the repository's providing the information to the client. Operations such as "delete a message" fall into the first category; operations like "send a list of mailboxes" fall into the second category.
DMSPがすぐに1組のメール州(地方の、そして、グローバルな)を操ることができるので、すべてのDMSP操作が原子であることは、非常に重要です。 どんなDMSP操作の失敗も一貫して、知られている状態の州に両方を残さなければなりません。 この理由で、明白な承認が操作創始者によって受けられない場合、DMSP操作は、失敗したように定義されます。 この承認はすべてのDMSP操作がなる2つの広いカテゴリに基づいて2つの基本的なフォームの1つを取ることができます。 まず最初に操作が何らかのメール州の変更を実行するという要求であるかもしれない、その場合、倉庫は「OK」か「失敗」のどちらかがある要求を承諾するでしょう(その場合、また、失敗の理由を返します)。 2番目に、操作が情報に関する要求であるかもしれない、その場合、倉庫が情報をクライアントに提供することによって、要求は承諾されます。 「メッセージを削除してください」などの操作は最初のカテゴリになります。 「メールボックスのリストを送ってください」のような操作は2番目のカテゴリになります。
Following are a list of DMSP operations by object type, their block types and arguments, and their expected acknowledgement block types. Each DMSP block has a different number; the first digit of each block type defines the object being manipulated: Operations numbered 5xx are general, operations numbered 6xx are user operations, operations numbered 7xx are client operations, operations numbered 8xx are mailbox and address operations, and operations numbered 11xx are message operations.
以下に、オブジェクト・タイプによるDMSP操作のリスト、彼らのゴシック体、議論、および彼らの予想された承認ゴシック体はいます。 それぞれのDMSPブロックには、異なった数があります。 それぞれのゴシック体の最初のケタは操作されるオブジェクトを定義します: 操作の番号付の5xxは一般的です、そして、操作の番号付の6xxはユーザ操作です、そして、操作の番号付の7xxはクライアント操作です、そして、操作の番号付の8xxはメールボックスとアドレス操作です、そして、操作の番号付の11xxはメッセージ操作です。
Blocks marked "=>" flow from client to repository; blocks marked "<="
flow from repository to client. If more than one block can be sent,
the choices are delimited by "or" ("|") characters.
ブロックは、クライアントから倉庫まで「=>」が流れであるとマークしました。 ブロックは、倉庫からクライアントまで「<=」が流れであるとマークしました。 1ブロック以上を送ることができるなら、“or"が選択を区切る、(「|」、)、キャラクタ。
Clark & Lambert [Page 6]
クラークとランバート[6ページ]
RFC 984 May 1986 PCMAIL
RFC984 1986年5月のPCMAIL
For clarity, each block type is put in a human- understandable form. The block number is followed by an operation name; this name is never transmitted as part of a USP block. Block arguments are identified by name and type, and enclosed in square brackets. "Record" data types are described by a list of "field-name:field-type" pairs contained in square brackets. "Choice" data types are described by a list of "tag:tag-name" pairs contained in square brackets. USP data types are abbreviated as follows:
明快において、各ゴシック体は人間の理解できるフォームに入れられます。 操作名は街区番号のあとに続いています。 この名前は1つのUSPブロックの一部として決して伝えられません。 ブロック議論は、名前とタイプによって特定されて、角括弧で同封されます。 「記録的な」データ型は組が角括弧に含んだ「フィールド名: フィールド・タイプ」のリストによって説明されます。 「特選している」データ型は組が角括弧に含んだ「タグ: タグ名」のリストによって説明されます。 USPデータ型は以下の通り簡略化されています:
Primitive data types:
基本データ型:
- string: str
- 以下を結んでください。 str
- cardinal: card
- 枢機卿: カード
- long-cardinal: Lcard
- 長い枢機卿: Lcard
- integer: int
- 整数: int
- long-integer: Lint
- 長整数型: リント
- boolean: bool
- 論理演算子: bool
Compound data types:
データ型を合成してください:
- sequence: SEQ
- 系列: SEQ
- array: AR
- 以下を整列させてください。 アルゴン
- record: REC
- 以下を記録してください。 REC
- choice: CH
- 選択: CH
4.1. General operations
4.1. 一般操作
The first group of DMSP operations perform general functions that
operate on no one particular class of object. DMSP has six
general operations, which provide the following services:
DMSP操作の最初のグループはオブジェクトのどんな1つの特定のクラスも経営しない一般的な機能を実行します。 DMSPには、6つの一般的な操作があります:(操作は以下のサービスを提供します)。
If either a client or the repository thinks the other is
malfunctioning, they can send an "abort-request". An
abort-request is never acknowledged; after the request is sent,
the sender immediately closes the USP connection and returns
control to its application.
クライアントか倉庫がもう片方であると考えるどちらかが誤動作しているなら、彼らは「アボート要求」を送ることができます。 アボート要求は決して承諾されません。 要求を送った後に、送付者は、すぐに、USP接続を終えて、コントロールをアプリケーションに返します。
=> 503 (abort-request) [why:str]
=>503(アボート要求)[なぜ: str]
Clark & Lambert [Page 7]
クラークとランバート[7ページ]
RFC 984 May 1986 PCMAIL
RFC984 1986年5月のPCMAIL
DMSP provides a limited remote debugging facility via the
"start-debug" and "end-debug" operations. When a client sends a
"start-debug" request, the repository enables its idea of
remote-debugging. The exact definition of remote debugging is
implementation dependent; the current repository implementation
simply writes debugging information to a special file. The
"end-debug" request disables remote debugging.
DMSPは「スタートデバッグ」と「終わりデバッグ」操作で限られた遠隔デバッギング施設を提供します。 クライアントが「スタートデバッグ」要求を送るとき、倉庫は遠隔デバッギングの考えを可能にします。 遠隔デバッギングの正確な定義は実装に依存しています。 現在の倉庫実装は単に特別なファイルにデバッグ情報を書きます。 「終わりデバッグ」要求は遠隔デバッギングを無効にします。
=> 504 (start-debug) []
=>504(スタートデバッグ)[]
<= 500 (ok) [] |
501 (failure) [why:str]
<= 500(OK)[]| 501 (失敗)[なぜ: str]
or
または
=> 505 (end-debug) []
=>505(終わりデバッグ)[]
<= 500 (ok) []
<= 500(OK)[]
In order to prevent protocol version skew between clients and the
repository, DMSP provides a "send-version" operation. The client
supplies its DMSP version number as an argument; the operation
succeeds if the supplied version number matches the repository's
DMSP version number. It fails if the two version numbers do not
match.
DMSPがクライアントと倉庫の間のプロトコルバージョン斜行を防ぐために提供する、「バージョンを発信させる、」 操作 クライアントは議論としてDMSPバージョン番号を供給します。 供給されたバージョン番号が倉庫のDMSPバージョン番号に合っているなら、操作は成功します。 2つのバージョン番号が合っていないなら、それは失敗します。
=> 506 (send-version) [version-number:card]
=>506(バージョンを発信させている)[バージョン番号: カード]
<= 500 (ok) [] |
501 (failure) [why:str]
<= 500(OK)[]| 501 (失敗)[なぜ: str]
DMSP also provides clients with the ability to send an arbitrary
text message to the repository. The "log-message" operation takes
as an argument a string of arbitrary length; the repository
accepts the string; what is done with the string is
implementation-dependent.
また、DMSPは任意のテキストメッセージを倉庫に送る能力をクライアントに提供します。 「ログメッセージ」操作は議論として任意の長さのストリングをみなします。 倉庫はストリングを受け入れます。 ひもで行われることは実装依存しています。
=> 507 log-message[message:str]
=>507ログメッセージ[メッセージ: str]
<= 500 (ok) [] |
501 (failure) [why:str]
<= 500(OK)[]| 501 (失敗)[なぜ: str]
Finally, users can send mail to other users via the "send-message"
operation. The message must have an Internet-style header as
defined by NIC RFC-822. The repository takes the message and
distributes it to the mailboxes specified on the "to:", "cc:", and
"bcc:" fields of the message header. If one or more of the
を通して最終的に、ユーザが他のユーザにメールを送ることができる、「メッセージを発信させる、」 操作。 メッセージには、NIC RFC-822によって定義されるようにインターネットスタイルヘッダーがなければなりません。 倉庫は、伝言を受け取て、「以下のこと」、「cc:」、および「bcc:」で指定されたメールボックスにそれを分配します。 メッセージヘッダーの分野。 1つか、より多く
Clark & Lambert [Page 8]
クラークとランバート[8ページ]
RFC 984 May 1986 PCMAIL
RFC984 1986年5月のPCMAIL
mailboxes exists outside the repository's user community, the
repository is responsible for handing the message to a local SMTP
server.
メールボックスは倉庫のユーザーコミュニティの外に存在していて、倉庫はローカルのSMTPサーバーにメッセージを手渡すのに原因となります。
An OK block is sent from the repository only if the entire message
was successfully transmitted. If the message was destined for the
Internet, the send-message operation is successful if the message
was successfully transmitted to the local SMTP server.
首尾よく全体のメッセージを送った場合にだけ、倉庫からOKブロックを送ります。 メッセージがインターネットに運命づけられたなら、メッセージが首尾よくローカルのSMTPサーバーに送られたなら、メッセージを発信させている操作はうまくいっています。
=> 508 (send-message) [message:SEQ[str]]
=>508(メッセージを発信させている)[メッセージ: SEQ[str]]
<= 500 (ok) [] |
501 (failure) [why:str]
<= 500(OK)[]| 501 (失敗)[なぜ: str]
4.2. User operations
4.2. ユーザ操作
The next series of DMSP operations manipulates user objects. The
most common of these operations are "login" and "logout". A
client must perform a login operation before being able to access
a user's mail state. A DMSP login block contains five items: (1)
the user's name, (2) the user's password, (3) the name of the
client performing the login, (4) a flag telling the repository to
create a client object for the client if one does not exist, and
(5) a flag set to TRUE if the client wishes to operate in "batch
mode" and FALSE if the client wishes to operate in "interactive"
mode. The flag value allows the repository to tune internal
parameters for either mode of operation.
DMSP操作の次のシリーズはユーザオブジェクトを操作します。 これらの操作で最も変哲もないのは、「ログイン」であり、「ログアウトします」。 ユーザのメール状態にアクセスできる前に、クライアントはログイン操作を実行しなければなりません。 DMSPログインブロックは5つの項目を含んでいます: (1) クライアントが「対話的な」モードで作動したいなら(3) (2) ユーザのパスワード、(4) ログインを実行しているクライアント、旗の名前が、(5) クライアントの1つが存在していないか、そして、クライアントが「バッチ・モード」で作動したいならTRUEに用意ができている旗とFALSEのためにクライアントオブジェクトを作成するように倉庫に言うユーザの名前。 旗の値は、運転モードのための内部のパラメタを調整するために倉庫を許容します。
The repository can return either an OK block (indicating
successful authentication), a FAILURE block (indicating failed
authentication), or a FORCE-RESET block. This last is sent if the
client logging in has been marked as "inactive" by the repository
(clients are marked inactive if they have not connected to the
repository in over a week). The FORCE-RESET block indicates that
the client should erase its local mail state and pull over a
complete version of the repository's mail state. This is done on
the assumption that so many mail state changes have been made in a
week that it would be inefficient to perform a normal
synchronization.
倉庫はOKブロック(うまくいっている認証を示す)、FAILUREブロック(失敗した認証を示す)、またはFORCE-RESETブロックを返すことができます。 倉庫のそばで「不活発である」としてログインしているクライアントをマークしたなら(彼らが1週間以上倉庫に接続しないなら、クライアントは不活発であるとマークされます)、最後にこれを送ります。 FORCE-RESETブロックは、クライアントが地方のメール状態を消して、倉庫のメール状態の完全なバージョンの上で引くべきであるのを示します。 とても多くのメール州の変更が1週間で行われたので通常の同期を実行するのが効率が悪いだろうという前提でこれをします。
=> 600 (login) [user:str, password:str, client:str,
create-client-object?:bool,
batch-mode-flag:bool]
=>600(ログインします)[クライアント: ユーザ: str、パスワード: str、str、クライアントオブジェクトを作成してください--バッチモード旗: : bool、bool]
<= 500 (ok) [] |
501 (failure) [why:str] |
705 (force-client-reset) []
<= 500(OK)[]| 501 (失敗)[なぜ: str]| 705 (力のクライアントリセット)[]
Clark & Lambert [Page 9]
クラークとランバート[9ページ]
RFC 984 May 1986 PCMAIL
RFC984 1986年5月のPCMAIL
When a client is finished interacting with the repository, it
performs a logout operation. This allows the repository to
perform any necessary cleanup before closing the USP connection.
ログアウトしてください。クライアントが倉庫と対話し終わっているとき、aを実行する、操作。 これで、USP接続を終える前に、倉庫はどんな必要なクリーンアップも実行できます。
=> 601 (logout) []
=>601(ログアウトします)[]
<= 500 (ok) []
<= 500(OK)[]
DMSP also provides "add-user" and "remove-user" operations, which
allow system administrators to remotely add new users to, and
remove users from, the repository. These operations are
privileged; the repository authenticates the user requesting the
operation before performing an add-user or remove-user operation.
Both operations require the name of the user to be added or
removed; the add-user operation also requires a default password
to assign the new user.
また、DMSPが提供する、「ユーザを加える、」、「ユーザを外す、」 操作。(その操作は、倉庫からシステム管理者が新しいユーザを離れて加えるのを許容して、ユーザを外します)。 これらの操作は特権があります。 倉庫はユーザを加えているか、またはユーザを外している操作を実行する前に操作を要求するユーザを認証します。 両方の操作は、ユーザの名前が加えられるか、または取り除かれるのを必要とします。 また、ユーザを加えている操作は、新しいユーザを選任するためにデフォルトパスワードを必要とします。
=> 602 (add-user) [user:str, password:str]
=>602(ユーザを加えている)[パスワード: ユーザ: str、str]
<= 500 (ok) [] |
501 (failure) [why:str]
<= 500(OK)[]| 501 (失敗)[なぜ: str]
=> 603 (remove-user) [user:str]
=>603(ユーザを外している)[ユーザ: str]
<= 500 (ok) [] |
501 (failure) [why:str]
<= 500(OK)[]| 501 (失敗)[なぜ: str]
A user can change his password via the "set-password" operation.
The operation works much the same as the UNIX change-password
operation, taking as arguments the user's current password and a
desired new password. If the current password given matches the
user's current password, the user's current password is changed to
the new password given.
ユーザは「セットパスワード」操作で彼のパスワードを変えることができます。 操作はUNIX変化パスワード操作への大体同じことを扱います、議論としてユーザの現在のパスワードと必要な新しいパスワードをみなして。 与えられた現在のパスワードがユーザの現在のパスワードに合っているなら、ユーザの現在のパスワードは与えられた新しいパスワードに変わります。
=> 604 (set-password) [old-password:str,
new-password:str]
=>604(セットパスワード)[新しいパスワード: 古いパスワード: str、str]
<= 500 (ok) [] |
501 (failure) [why:str]
<= 500(OK)[]| 501 (失敗)[なぜ: str]
Clark & Lambert [Page 10]
クラークとランバート[10ページ]
RFC 984 May 1986 PCMAIL
RFC984 1986年5月のPCMAIL
4.3. Client operations
4.3. クライアント操作
DMSP provides four operations to manipulate client objects. The
first, "list-clients", tells the repository to send the user's
client list to the requesting client. The list takes the form of
a series of (name, status pairs).
DMSPは、クライアントオブジェクトを操作するために四則を提供します。 「リストクライアント」という1番目は、ユーザの顧客リストを要求しているクライアントに送るように倉庫に言います。 リストは(名前、状態組)のシリーズの形を取ります。
=> 700 (list-clients) []
=>700(リストクライアント)[]
<= 701 (client-list) [client-list:SEQ[
REC[name:str, status:card]]]
<= 701 (顧客リスト)[顧客リスト: SEQ[REC[名前: str、状態: カード]]]
The "add-client" operation allows a user to add a client object to
his list of client objects. Although the login operation
duplicates this functionality via the "create-this-client?" flag,
the add-client operation is a useful means of creating a number of
new client objects while logged into the repository via an
existing client. The add-client operation requires the name of
the client to add.
「クライアントを加える、」 操作、ユーザが彼のクライアントオブジェクトのリストにクライアントオブジェクトを追加するのを許容します。 ログイン操作は「このクライアントを創造していますか?」の旗でこの機能性をコピーしますが、クライアントを加えている操作は既存のクライアントを通して倉庫に登録されている間、多くの新しいクライアントオブジェクトを作成する役に立つ手段です。 クライアントを加えている操作は、加えるためにクライアントの名前を必要とします。
=> 702 (add-client) [client:str]
=>702(クライアントを加えている)[クライアント: str]
<= 500 (ok) [] |
501 (failure) [why:str]
<= 500(OK)[]| 501 (失敗)[なぜ: str]
The most common failure mode for this operation is an attempt to
add a client that already exists.
この操作のための最も一般的な故障モードは既に存在するクライアントを加える試みです。
The "remove-client" operation removes an existing client object
from a user's client list. The client being removed can be the
client requesting the operation. The remove-client operation
requires the name of the client to remove.
「クライアントを外す、」 操作はユーザの顧客リストから既存のクライアントオブジェクトを取り除きます。 外されているクライアントは操作を要求するクライアントであるかもしれません。 クライアントを外している操作は、取り外すためにクライアントの名前を必要とします。
=> 703 (remove-client) [client:str]
=>703(クライアントを外している)[クライアント: str]
<= 500 (ok) [] |
501 (failure) [why:str]
<= 500(OK)[]| 501 (失敗)[なぜ: str]
The most common failure mode here is an attempt to remove a
non-existent client. This is a typical failure mode for any DMSP
operation which operates on a named object.
ここの最も一般的な故障モードは実在しないクライアントを外す試みです。 これは命名されたオブジェクトを作動させるどんなDMSP操作のための典型的な故障モードです。
The last client operation, "reset-client", causes the repository
to mark all messages in the user's mail state as having changed
since the client last logged in. When a client next synchronizes
with the repository, it will end up receiving a complete copy of
the repository's global mail state. This is useful for two
「リセットクライアント」という最後のクライアント操作で、倉庫はクライアントが最後にログインして以来変化しているとしてユーザのメール状態のすべてのメッセージをマークします。 次のクライアントが倉庫に連動すると、それは結局、完本の倉庫のグローバルなメール状態を受けるでしょう。 これは2の役に立ちます。
Clark & Lambert [Page 11]
クラークとランバート[11ページ]
RFC 984 May 1986 PCMAIL
RFC984 1986年5月のPCMAIL
reasons. First, a client's local mail state could easily become
lost or damaged, especially if it is stored on a floppy disk.
Second, if a client has been marked as inactive by the repository,
the reset-client operation provides a fast way of resynchronizing
with the repository, assuming that so many differences exist
between the local and global mail states that a normal
synchronization would take far too much time.
理由。 まず最初に、クライアントの地方のメール状態は容易に無くなるか破損するようになるかもしれません、特にそれがフロッピーディスクに保存されるなら。 2番目に、クライアントが倉庫のそばで不活発であるとしてマークされたなら、リセットクライアント操作は再連動する速い方法に倉庫を提供します、とても多くの違いが地方の、そして、グローバルなメール州の間に存在しているので通常の同期が遠くにあまりに多くの時間がかかると仮定して。
=> 704 (reset-client) [client:str]
=>704(リセットクライアント)[クライアント: str]
<= 500 (ok) [] |
501 (failure) [why:str]
<= 500(OK)[]| 501 (失敗)[なぜ: str]
4.4. Mailbox operations
4.4. メールボックス操作
DMSP supports five operations that manipulate mailbox objects.
First, "list-mailboxes" has the repository send to the requesting
client information on each mailbox. This information consists of
the mailbox name, total message count, unseen message count, and
"next available UID". This operation is useful in synchronizing
local and global mail states, since it allows a client to compare
the user's global mailbox list with a client's local mailbox list.
The list of mailboxes also provides a quick summary of each
mailbox's contents without having the contents present.
DMSPはメールボックスオブジェクトを操作する5つの操作をサポートします。 まず最初に、「リストメールボックス」は倉庫をそれぞれのメールボックスの要求しているクライアント情報に発信させます。 この情報はメールボックス名、総メッセージカウント、カウント、および「次の利用可能なUID」という見えないメッセージから成ります。 この操作は地方の、そして、グローバルなメール州を連動させる際に役に立ちます、クライアントがそれでクライアントのローカルのメールボックスリストとユーザのグローバルなメールボックスリストを比べることができるので。 また、コンテンツプレゼントを持っていなくて、メールボックスのリストは各メールボックスのコンテンツの短い概要を提供します。
=> 800 (list-mailboxes) []
=>800(リストメールボックス)[]
<= 801 (mailbox-list) [mailbox-list:SEQ[
REC[mailbox:str,
next-UID:Lcard,
num-msgs:card,
num-unseen-msgs:card]]]
<= 801 (メールボックスリスト)[メールボックスリスト: SEQ[REC[メールボックス: 次のUID: str、Lcard、num-msgs: numの見えないmsgs: カード、カード]]]
The "add-mailbox" has the repository create a new mailbox and
attach it to the user's list of mailboxes. An address object
binding the (user-name, mailbox-name) pair to an RFC-822-style
address is automatically created and placed in the repository's
list of address objects. This allows mail coming from the
Internet to be correctly routed to the new mailbox.
「メールボックスを加える、」、倉庫が新しいメールボックスを作成して、ユーザのメールボックスのリストにそれを付けるのを持っています。 RFC822スタイルへの(ユーザ名、メールボックス名)組が記述するアドレス物の結合は、倉庫のアドレス物のリストに自動的に作成されて、置かれます。 これは、インターネットから来るメールが正しく新しいメールボックスに発送されるのを許容します。
=> 802 (add-mailbox) [mailbox:str]
=>802(メールボックスを加えている)[メールボックス: str]
<= 500 (ok) [] |
501 (failure) [why:str]
<= 500(OK)[]| 501 (失敗)[なぜ: str]
"Remove-mailbox" removes a mailbox from the user's list of
mailboxes. All messages within the mailbox are also deleted and
「メールボックスを取り外す、」 ユーザのメールボックスのリストからメールボックスを取り外します。 そしてまた、メールボックスの中のすべてのメッセージが削除される。
Clark & Lambert [Page 12]
クラークとランバート[12ページ]
RFC 984 May 1986 PCMAIL
RFC984 1986年5月のPCMAIL
permanently removed from the system. Any address objects binding
the mailbox name to RFC-822-style mailbox addresses are also
removed from the system.
永久に、システムから取り除きます。 また、システムからRFC822スタイルメールボックスアドレスにメールボックス名を縛るどんなアドレス物も取り除きます。
=> 803 (remove-mailbox) [mailbox:str]
=>803(メールボックスを取り外している)[メールボックス: str]
<= 500 (ok) [] |
501 (failure) [why:str]
<= 500(OK)[]| 501 (失敗)[なぜ: str]
DMSP also has an "expunge-mailbox" operation. Any message can be
deleted and "undeleted" at will. Deletions are made permanent by
performing an expunge-mailbox operation. The expunge operation
causes the repository to look through a named mailbox, removing
from the system any messages marked "deleted".
また、DMSPが持っている、「メールボックスを梢消する、」 操作。 どんなメッセージも自由自在に削除して、"非削除"であることができます。 メールボックスを梢消している操作を実行することによって、削除を永久的にします。 命名されたメールボックスに目を通して、システムからどんなメッセージも取り除くことへの倉庫が「削除されている」とマークした操作原因を梢消してください。
=> 808 expunge-mailbox[mailbox:str]
=>808、メールボックスを梢消します。[メールボックス: str]
<= 500 (ok) [] |
501 (failure) [why:str]
<= 500(OK)[]| 501 (失敗)[なぜ: str]
Finally, "reset-mailbox" causes the repository to mark all the
messages in a named mailbox as having changed since the current
client last logged in. When the client next synchronizes with the
repository, it will receive a complete copy of the named mailbox's
mail state. This operation is merely a more specific version of
the reset-client operation (which allows the client to pull over a
complete copy of the user's global mail state). Its primary use
is for mailboxes whose contents have accidentally been destroyed
locally.
最終的に、「リセットメールボックス」は倉庫に現在のクライアントが最後にログインして以来変化しているとして命名されたメールボックスの中のすべてのメッセージをマークさせます。 次のクライアントが倉庫に連動すると、それは完本の命名されたメールボックスのメール状態を受けるでしょう。 この操作は単にリセットクライアント操作(クライアントは完本のユーザのグローバルなメール状態の上で引くことができる)の、より特定のバージョンです。 第一の使用は偶然局所的にコンテンツを破壊してあるメールボックスのためのものです。
=> 809 (reset-mailbox) [mailbox:str]
=>809(リセットメールボックス)[メールボックス: str]
<= 500 (ok) [] |
501 (failure) [why:str]
<= 500(OK)[]| 501 (失敗)[なぜ: str]
4.5. Address operations
4.5. アドレス操作
DMSP provides three operations that allow users to manipulate
address objects. First, the "list-address" operation returns a
list of address objects associated with a particular (user-name,
mailbox-name) pair.
DMSPはユーザがアドレス物を操作できる3つの操作を提供します。 まず最初に、「リストアドレス」操作は特定(ユーザ名、メールボックス名)の組に関連しているアドレス物のリストを返します。
=> 804 (list-addresses) [mailbox:str]
=>804(リストアドレス)[メールボックス: str]
<= 501 (failure) [why:str] |
805 (address-list) [address-list:SEQ[str]]
<= 501 (失敗)[なぜ: str]| 805 (住所録)[住所録: SEQ[str]]
Clark & Lambert [Page 13]
クラークとランバート[13ページ]
RFC 984 May 1986 PCMAIL
RFC984 1986年5月のPCMAIL
The "add-address" operation adds a new address object that
associates a (user-name, mailbox-name) pair with a given
RFC-822-style mailbox address.
「アドレスを加える、」 操作、(ユーザ名、メールボックス名)組を与えられたRFC822スタイルメールボックスアドレスに関連づける新しいアドレス物を加えます。
=> 806 (add-address) [mailbox:str,
RFC-822-mail-address:str]
=>806(アドレスを加えている)[RFC822郵便の宛先: メールボックス: str、str]
<= 500 (ok) [] |
501 (failure) [why:str]
<= 500(OK)[]| 501 (失敗)[なぜ: str]
Finally, the "remove-address" operation destroys the address
object binding the given RFC-822-style mail address and the given
(user-name, mailbox-name) pair.
最終的である、「アドレスを取り外す、」 操作、与えられたRFC822スタイル郵便の宛先と与えられた(ユーザ名、メールボックス名)組を縛るアドレス物を破壊します。
=> 807 (remove-address) [mailbox:str,
RFC-822-mail-address:str]
=>807(アドレスを取り外している)[RFC822郵便の宛先: メールボックス: str、str]
<= 500 (ok) [] |
501 (failure) [why:str]
<= 500(OK)[]| 501 (失敗)[なぜ: str]
4.6. Message operations
4.6. メッセージ操作
The most commonly-manipulated Pcmail objects are messages; DMSP
therefore provides special message operations to allow efficient
synchronization, as well as a set of operations to perform
standard message-manipulation functions. In the following
paragraphs, the terms "message" and "descriptor" will be used
interchangeably.
最も多くの一般的に操られたPcmail物がメッセージです。 したがって、DMSPは、効率的な同期、および1セットの操作が標準のメッセージマニピュレーション機能を実行するのを許容するために特別教書操作を提供します。 以下のパラグラフでは、用語「メッセージ」と「記述子」は互換性を持って使用されるでしょう。
A client can request a particular message's flag values with the
"get-descriptor-flags" operation. The repository sends over an
array of boolean values, eight of which are system defined, and
eight of which are user defined and ignored by the repository.
クライアントは「記述子旗を手に入れてください」という操作で特定のメッセージの旗の値を要求できます。 倉庫はブール値の勢ぞろいを移動します。(8つのそれが定義されたシステムであり、8つのそれがブール値のための倉庫によって定義されて、無視されたユーザです)。
=> 1100 (get-descriptor-flags) [mailbox:str,
uid:Lcard]
=>1100(記述子旗を手に入れてください)[uid: メールボックス: str、Lcard]
<= 1101 (descriptor-flags) [flags:SEQ[bool]] |
501 (failure) [why:str]
<= 1101(記述子旗)[旗: SEQ[bool]]| 501 (失敗)[なぜ: str]
A user may request a series of descriptors with the
"get-descriptors" operation. The series is identified by a pair
of message UIDs, representing the lower and upper bounds of the
list. Since UIDs are defined to be monotonically increasing
numbers, a pair of UIDs is sufficient to completely identify the
series of descriptors. The repository returns a sequence of
"choices". Elements of the sequence can either be descriptors, in
ユーザが一連の記述子を要求するかもしれない、「記述子を得る、」 操作。 シリーズはリストの1組のメッセージUIDs、下側を表して、および上限によって特定されます。 UIDsが数を単調に増加させているように定義されるので、1組のUIDsは記述子のシリーズを完全に特定するために十分です。 倉庫は「選択」の系列を返します。 系列の原理は記述子、コネであるかもしれません。
Clark & Lambert [Page 14]
クラークとランバート[14ページ]
RFC 984 May 1986 PCMAIL
RFC984 1986年5月のPCMAIL
which case the choice is tagged as a descriptor, or they can be
notification that the requested message has been expunged
subsequent to the client's last connection to the repository.
どれが選択をケースに入れるかは記述子としてタグ付けをされるか、それらが要求されたメッセージがクライアントの最後の接続において倉庫にその後で梢消されたという通知であるかもしれません。
=> 1102 (get-descriptors) [mailbox:str,
low-UID:Lcard,
high-UID:Lcard]
=>1102(記述子を得ている)[高いUID: メールボックス: str、低いUID: Lcard、Lcard]
<= 501 (failure) [why:str] |
1103 (descriptor-list) [descriptor-list:SEQ[ CH[
expunged[uid:Lcard]
descriptor[REC[UID:Lcard,
flags:SEQ[bool],
from-field:str,
to-field:str,
date-field:str,
subject-field:str,
num-bytes:Lcard,
num-lines:Lcard]
]]]]
<= 501 (失敗)[なぜ: str]| 1103(記述子リスト)[記述子リスト: SEQ[CH[記述子[REC旗: UID: Lcard、SEQ[bool]、分野から: 分野に: str、年月日欄: str、strが: strを対象でさばいて、: num-バイトがLcardであり、[: num-線はLcardである]]を梢消します[uid: Lcard]]]]
The "get-changed-descriptors" operation is intended for use during
state synchronization. Whenever a descriptor changes state (is
deleted, for example), the repository notes those clients which
have not yet recorded the change locally. Get-changed-descriptors
has the repository send to the client a given number of
descriptors which have changed since the client's last
synchronization. The list sent begins with the earliest-changed
descriptor.
「変えられた記述子を得てください」という操作は使用のために州の同期の間、意図します。 記述子が状態(例えば、削除される)を変えるときはいつも、倉庫はそれらのクライアントに注意します(まだ局所的に変化を記録していません)。 変えられた記述子を得てください。倉庫にクライアントのものが同期が続くので変化した与えられた数の記述子をクライアントに送らせます。 送られたリストは最も早く変えられた記述子で始まります。
=> 1105 (get-changed-descriptors) [mailbox:str,
max-to-send:card]
=>1105(変えられた記述子を得てください)[送る最大: メールボックス: str、カード]
<= 501 (failure) why:str] |
1103 (descriptor-list) [descriptor-list:SEQ[
CH[
expunged[uid:Lcard]
descriptor[REC[UID:Lcard,
flags:SEQ[bool],
from-field:str,
to-field:str,
date-field:str,
subject-field:str,
num-bytes:Lcard,
num-lines:Lcard]
]]]]
<= 501(失敗) なぜ: str] | 1103(記述子リスト)[記述子リスト: SEQ[CH[記述子[REC旗: UID: Lcard、SEQ[bool]、分野から: 分野に: str、年月日欄: str、strが: strを対象でさばいて、: num-バイトがLcardであり、[: num-線はLcardである]]を梢消します[uid: Lcard]]]]
Clark & Lambert [Page 15]
クラークとランバート[15ページ]
RFC 984 May 1986 PCMAIL
RFC984 1986年5月のPCMAIL
Once the changed descriptors have been looked at, a user will want
to inform the repository that the current client has recorded the
change locally. The "reset-changed-descriptors" causes the
repository to mark as "seen by current client" a given number of
changed descriptors, starting with the changed descriptor with
lowest UID.
変えられた記述子がいったん見られると、ユーザは、現在のクライアントが局所的に変化を記録したことを倉庫に知らせたくなるでしょう。 「リセットの変えられた記述子」は与えられた数の変えられた記述子を「現在のクライアントで、見る」ので、マークへの倉庫を引き起こします、最も低いUIDと共に変えられた記述子から始まって。
=> 1106 (reset-changed-descriptors) [
mailbox:str,
number-to-reset:card]
=>1106(リセットは記述子を変えました)[リセットする数: メールボックス: str、カード]
<= 500 (ok) [] |
501 (failure) [why:str]
<= 500(OK)[]| 501 (失敗)[なぜ: str]
Message bodies are transmitted from repository to user with the
"get-message-text" operation. The separation of "get-descriptors"
and "get-message-text" operations allows clients with small
amounts of disk storage to obtain a small message summary (via
"get-descriptors" or "get-changed-descriptors") without having to
pull over the entire message.
メッセージ本体が倉庫からユーザまで伝えられる、「メッセージ・テキストを得る、」 操作。 を通して分離、「記述子を得る、」、「メッセージ・テキストを得る、少量のディスク格納のクライアントが」 操作で小さいメッセージ概要を得ることができる、(「記述子を得る、」 「変えられた記述子を得てください」) 引く必要はなくて、全体のメッセージの上で引いてください。
=> 1107 (get-message-text)[mailbox:str,
uid:Lcard]
=>1107(メッセージ・テキストを得ている)[uid: メールボックス: str、Lcard]
<= 501 (failure) [why:str] |
1110 (message) [message:SEQ[str]]
<= 501 (失敗)[なぜ: str]| 1110(メッセージ)[メッセージ: SEQ[str]]
Frequently, a message may be too large for some clients to store
locally. Users can still look at the message contents via the
"print-message" operation. This operation has the repository send
a copy of the message to a named printer. The printer name need
only have meaning to the particular repository implementation;
DMSP transmits the name only as a means of identification.
頻繁に、メッセージは何人かのクライアントが局所的に格納できないくらい大きいかもしれません。 ユーザは「印刷メッセージ」操作でまだメッセージ内容を見ることができます。 この操作で、倉庫はメッセージのコピーを命名されたプリンタに送ります。 プリンタ名は特定の倉庫実現に意味を持つだけでよいです。 DMSPは単に識別の手段として名前を伝えます。
=> 1108 (print-message) [mailbox:str,
uid:Lcard,
printer-name:str]
=>1108(印刷メッセージ)[プリンタ名: メールボックス: str、uid: Lcard、str]
<= 500 (ok) [] |
501 (failure) [why:str]
<= 500(OK)[]| 501 (失敗)[なぜ: str]
The user can set and clear any of the 16 descriptor flags with the
"set-flag" operation. The desired flag is set or cleared
according to the operation arguments.
ユーザは、セットして、「セット旗」操作で16個の記述子旗からいくらか取り除くことができます。 操作議論に従って、必要な旗は、設定されるか、またはきれいにされます。
Clark & Lambert [Page 16]
クラークとランバート[16ページ]
RFC 984 May 1986 PCMAIL
RFC984 1986年5月のPCMAIL
=> 1109 (set-flag) [mailbox:str,
uid:Lcard,
flag-number:card,
flag-setting:bool]
=>1109(セット旗)[旗設定: メールボックス: str、uid: Lcard、旗番号: カード、bool]
<= 500 (ok) [] |
501 (failure) [why:str]
<= 500(OK)[]| 501 (失敗)[なぜ: str]
Copying of one message into another mailbox is accomplished via
the "copy-message" operation.
別のメールボックスの中に1つのメッセージをコピーするのは「コピーメッセージ」操作で実行されます。
=> 1111 (copy-message) [source-mailbox:str,
target-mailbox:str,
source-uid:Lcard]
=>1111(コピーメッセージ)[ソース-uid: ソースメールボックス: str、目標メールボックス: str、Lcard]
<= 500 (ok) [] |
501 (failure) [why:str]
<= 500(OK)[]| 501 (失敗)[なぜ: str]
5. Client Architecture
5. クライアント構造
Clients are typically PCs; Pcmail's architecture must therefore take into account several characteristics common to PCs. First, PCs are cheap, therefore a user may well have more than one. Second, they are portable, therefore they are not expected to be constantly tied into a network. Finally, they are resource-poor, so they are not expected to be able to store a significant amount of state information locally. The following subsections describe the particular parts of Pcmail's client architecture that address these three characteristics.
通常、クライアントはPCです。 したがって、Pcmailの構造はPCに共通のいくつかの特性を考慮に入れなければなりません。 まず最初にPCが安い、したがって、ユーザには、1つ以上がたぶんあるでしょう。 2番目に、それらが携帯用である、したがって、絶えず彼らによってネットワークに結ばれないと予想されます。 最終的に、それらが資源の乏しいので、彼らが局所的にかなりの量の州の情報を格納できないと予想されます。 以下の小区分はこれらの3つの特性を記述するPcmailのクライアント構造の特定の部分について説明します。
5.1. Multiple clients
5.1. 複数のクライアント
The fact that Pcmail users may own more than one PC forms the
rationalization for the multiple client model that Pcmail uses. A
Pcmail user may have a PC client at home, a PC at an office, and
maybe even a third portable PC. Each client maintains a separate
copy of the user's mail state, hence Pcmail's distributed nature.
The notion of separate clients allows Pcmail users to access mail
state from several different locations.
Pcmailユーザが1PCを所有するかもしれないという事実はPcmailが使用する複数のクライアントモデルのための合理化を形成します。 Pcmailユーザには、PCクライアントが家、オフィスのPC、および多分第3の携帯用のPCにさえいるかもしれません。 各クライアントはユーザのメール状態、したがって、別々のコピーのPcmailの分配された本質を維持します。 別々のクライアントの概念で、Pcmailユーザはいくつかの別の場所からメール状態にアクセスできます。
Clark & Lambert [Page 17]
クラークとランバート[17ページ]
RFC 984 May 1986 PCMAIL
RFC984 1986年5月のPCMAIL
5.2. Synchronization
5.2. 同期
Since PCs are fairly portable, the likelihood of a PC's being
always connected to a network is relatively small. This is
another reason for each client's maintaining a local copy of a
user's mail state. The user can then manipulate the local mail
state while not connected to the network (and the repository).
This immediately brings up the problem of synchronization between
local and global mail states. The repository is continually in a
position to receive global mail state updates, either in the form
of incoming mail, or in the form of changes from other clients. A
client that is not always connected to the net cannot immediately
receive the global changes. In addition, the client's user can
make his own changes on the local mail state.
PCがかなり携帯用であるので、いつもネットワークに接続されたPCの存在の見込みは比較的小さいです。 これは各クライアントが地方のコピーのユーザのメール状態を維持する別の理由です。 そして、ユーザはネットワーク(そして、倉庫)に関連づけられていない間、地方のメール状態を操ることができます。 これはすぐに、地方の、そして、グローバルなメール州の間に同期の問題を持って来ます。 受信する立場では、絶えず、グローバルな郵便配達人がアップデートを述べるということであるか倉庫は入って来るメールの形、または他のクライアントからの変化の形でそうします。 いつもネットに接続されるというわけではないクライアントはすぐに、グローバルな変化を受けることができません。 さらに、クライアントのユーザは地方のメール状態で彼自身の変更を行うことができます。
Pcmail's architecture permits efficient synchronization between
client local mail states and the repository's global mail state.
Each client is identified in the repository by a client object
attached to the user. This object forms the basis for
synchronization between local and global mail states. Some of the
less common state changes include the adding and deleting of user
mailboxes and the adding and deleting of address objects.
Synchronization of these changes is performed via DMSP list
operations, which allow clients to compare their local versions of
mailbox and address object lists with the repository's global
version and make any appropriate changes. The majority of
possible changes to a user's mail state are in the form of changed
descriptors. Since most users will have a large number of
messages, and message states will change relatively often, special
attention needs to be paid to message synchronization.
Pcmailの構造はクライアントの地方のメール州と倉庫のグローバルなメール状態の間の効率的な同期を可能にします。 各クライアントは倉庫でユーザに愛着しているクライアント物によって特定されます。 この物は地方の、そして、グローバルなメール州の間で同期の基礎を形成します。 いくつかのそれほど一般的でない州の変化がアドレス物のユーザメールボックスの付加と削除、付加、および削除を含んでいます。 これらの変化の同期はDMSPリスト操作で実行されます。(クライアントは、メールボックスとアドレス物のリストの地元のバージョンを倉庫のグローバルなバージョンにたとえて、操作でどんな適切な変更も行います)。 ユーザのメール状態への可能な変化の大部分が変えられた記述子の形にあります。 ほとんどのユーザには多くのメッセージがあって、メッセージ州が比較的しばしば変化するので、特別な注意は、メッセージ同期に支払われる必要があります。
An existing descriptor can be changed in one of two ways: first,
one of its sixteen flags values can be changed (this encompasses
reading an unseen message, deleting a message, and expunging a
message). The second way to change a descriptor is via the
arrival of incoming mail or the copying of a message from one
mailbox to another. Both result in a new message being added to a
mailbox.
2つの方法の1つで既存の記述子を変えることができます: まず最初に、変えることができます(これが見えないメッセージを読むメッセージを削除するのを取り囲んで、メッセージを梢消して)16個の旗のひとりが、評価する。 入って来るメールの到着かメッセージの1個のメールボックスから別のメールボックスまでのコピーを通して記述子を変える2番目の方法があります。 両方がメールボックスに加えられる新しいメッセージをもたらします。
In both the above cases, synchronization is required between the
repository and every client that has not previously noted a
change. To keep track of which clients have noticed a global mail
state change and changed their local states accordingly, each
descriptor has associated with it a (potentially empty) "update
list" of client objects. The list identifies those clients which
have not yet recorded a change to that descriptor's state.
両方の上の場合では、同期が変化について上述していない倉庫とすべてのクライアントの間で必要です。 どのクライアントがグローバルなメール状態が変化するのに気付いて、変化したかに関する道が地元の州であることを保つために、それに従って、各記述子はクライアント物の(潜在的に空)の「アップデートリスト」をそれに関連づけました。 リストはそれらのクライアントを特定します(まだその記述子の状態への変化を記録していません)。
Clark & Lambert [Page 18]
クラークとランバート[18ページ]
RFC 984 May 1986 PCMAIL
RFC984 1986年5月のPCMAIL
When a client connects to the repository, it executes a DMSP
"get-changed-descriptors" operation. This causes the repository
to return a list of all descriptor objects that have the
requesting client on their update list. As the client receives
the changed descriptors, it can store them locally, thus updating
the local mail state. After a changed descriptor has been
recorded, the client uses the DMSP "reset-descriptors" operation
to remove itself from the descriptor's update list. That
descriptor will now not be sent to the client unless (1) it is
explicitly requested, or (2) it changes again.
クライアントが倉庫に接続するとき、それは「変えられた記述子を得てください」というDMSP操作を実行します。 これで、倉庫は要求しているクライアントがそれらのアップデートリストにいるすべての記述子物のリストを返します。 クライアントが変えられた記述子を受け取るのに応じて局所的にそれらを格納して、その結果、地方のメール状態をアップデートできます。 変えられた記述子が記録された後に、クライアントは、記述子のアップデートリストから立ち退くのにDMSP「リセット記述子」操作を使用します。 (1) それが明らかに要求されているか、または(2) 再び変化しない場合、その記述子は現在、クライアントに送られないでしょう。
In this manner, a client can run through its user's mailboxes,
getting all changed descriptors, incorporating them into the local
mail state, and marking the change as recorded.
クライアントは、ユーザのメールボックスを通してすべてを得ると記述子がこの様に変化したと述べることができます、地方のメール状態にそれらを組み入れて、記録されるとして変化をマークして。
5.3. Batch operation versus interactive operation
5.3. バッチ運転対対話的な操作
Because of the portable nature of most PCs, they may not always be
connected to the repository. Since each client maintains a local
mail state, Pcmail users can manipulate the local state while not
connected to the repository. This is known as "batch" operation,
since all changes are recorded by the client and made to the
repository's global state in a batch, when the client next
connects to the repository. Interactive operation occurs when a
client is always connected to the repository. In interactive
mode, changes made to the local mail state are immediately
propagated to the global state via DMSP operations.
ほとんどのPCの携帯用の自然のために、それらはいつも倉庫に接続されるかもしれないというわけではありません。 各クライアントが地方のメール状態を維持するので、Pcmailユーザは倉庫に接続されていない間、地方の状態を操ることができます。 これは「バッチ」操作として知られています、すべての変更をクライアントが記録して、倉庫の一括しているグローバルな状態にするので、次のクライアントが倉庫に接続するとき。 クライアントがいつも倉庫に接続されるとき、対話的な操作は起こります。 会話型では、地方のメール状態にされた変更はすぐに、DMSP操作でグローバルな状態に伝播されます。
In batch mode, interaction between client and repository takes the
following form: the client connects to the repository and sends
over all the changes made by the user to the local mail state.
The repository changes its global mail state accordingly. When all
changes have been processed, the client begins synchronization, to
incorporate newly-arrived mail, as well as mail state changes by
other clients, into the local state.
バッチ・モードで、クライアントと倉庫との相互作用は以下の形を取ります: クライアントは、倉庫に接続して、ユーザによって行われたすべての変更を地方のメール状態に移動します。 倉庫はそれに従って、グローバルなメール状態を変えます。 すべての変化を処理してあるとき、クライアントは新来のメールを取り入れるために同期を始めます、他のクライアントによるメール州の変化と同様に、地方の状態に。
In interactive mode, since local changes are immediately
propagated to the repository, the first part of batch-type
operation is eliminated. The synchronization process also
changes; interactive clients can periodically poll the repository
for a list of changes, synchronizing a small amount at a time.
会話型では、地域変化がすぐに倉庫に伝播されるので、バッチ型操作の最初の部分は排除されます。 また、同期の過程は変化します。 一度に少量を同期させて、対話的なクライアントは変化のリストのために定期的に倉庫に投票できます。
Clark & Lambert [Page 19]
クラークとランバート[19ページ]
RFC 984 May 1986 PCMAIL
RFC984 1986年5月のPCMAIL
5.4. Message summaries
5.4. メッセージ概要
Since PCs are assumed to have little in the way of disk storage, a
given client may never have enough room for a complete local copy
of a user's global mail state. This means that Pcmail's client
architecture must allow user's to obtain a clear picture of their
mail state without having all their messages present.
PCが少ししかディスク格納の方法で持っていないと思われて、与えられたクライアントは完全な地方のコピーのユーザのグローバルなメール状態に十分な余地を決して持っていないかもしれません。 これは、ユーザのものがPcmailのクライアント構造でそれらのすべてのメッセージプレゼントを持っているというわけではなくてそれらのメール状態の鮮明な映像を得ることができなければならないことを意味します。
Descriptors provide message information without taking up large
amounts of storage. Each descriptor contains a summary of
information on a message. This information includes the message
UID, its length in bytes and lines, its status (encoded in the
eight system-defined and eight user-defined flags), and portions
of its RFC-822 header (the "to:", "from:", "subject:" and "date:"
fields). All of this information can be encoded in a small
(around 100 bytes) data structure whose length is independent of
the size of the message it describes.
大容量ストレージを取らないで、記述子はメッセージ情報を提供します。 各記述子はメッセージの情報の概要を含んでいます。 この情報がRFC-822ヘッダーのメッセージUID、バイトで表現される長さ、線、状態(8では、システムで定義されるのと8個のユーザによって定義された旗をコード化する)、および一部を含んでいる、(「以下からの」「以下のこと」、「subject: 」 「日付:」 分野、) 長さがそれが説明するメッセージのサイズから独立している(およそ100バイト)の小さいデータ構造でこの情報のすべてをコード化できます。
Any client should be able to store a complete list of message
descriptors with little problem. This allows a user to get a
complete picture of his mail state without having all his messages
present locally. Short messages can reside on the client, along
with the descriptors, and long messages can either be printed via
the DMSP print-message operation, or specially pulled over via the
fetch-message-text operation.
どんなクライアントも問題でほとんどメッセージ記述子に関する全リストを格納できないべきです。 これで、ユーザは彼のすべてのメッセージを持っていることのない彼のメール状態の完全な絵を局所的に存在させることができます。 短いメッセージが記述子に伴うクライアントの上にあることができて、特に、長いメッセージをDMSP印刷メッセージ操作で印刷するか、またはフェッチメッセージ・テキスト操作で引くことができます。
6. Typical Client-Repository Interaction
6. 典型的なクライアント倉庫相互作用
The following example describes a typical communication session between the repository and a client. The client is one of three belonging to user "Fred". Its name is "office-client", and since Fred uses the client regularly to access his mail, the client is marked as "active". Fred has two mailboxes: "main" is where all of his current mail is stored; "archive" is where messages of lasting importance are kept. The example will run through a simple synchronization operation followed by a series of typical mail state manipulations. Typically, the synchronization will be performed by an application program that connects to the repository, logs in, synchronizes, and logs out.
以下の例は倉庫とクライアントとの典型的なコミュニケーションセッションについて説明します。 クライアントはユーザ「フレッド」に属す3の1つです。 名前は「オフィスクライアント」です、そして、フレッドが彼のメールにアクセスするのに定期的にクライアントを使用するので、クライアントは「アクティブである」としてマークされます。 フレッドは2個のメールボックスを持っています: 「メイン」は彼の現在のメールのすべてが格納されるところです。 「アーカイブ」は永久に重要なメッセージが保たれるところです。 例は簡単な同期操作を貫くでしょう、続いて、一連の典型的なメール州の操作を貫きます。 通常、同期は倉庫に接続して、ログインして、連動して、ログアウトするアプリケーション・プログラムによって実行されるでしょう。
For the example, all DMSP operations will be shown in a user-readable format. In reality, the operations would be sent as a stream of USP blocks consisting of a block-type number followed by a stream of bytes representing the block's arguments. Both the block name and its number are included for convenience.
例に関しては、すべてのDMSP操作がユーザ読み込み可能な形式で示されるでしょう。 ブロックの議論を表すバイトの流れでゴシック体番号から成るUSPブロックの小川が続いたので、ほんとうは、操作を送るでしょう。 ブロック名とその番号の両方が便宜のために含まれています。
Clark & Lambert [Page 20]
クラークとランバート[20ページ]
RFC 984 May 1986 PCMAIL
RFC984 1986年5月のPCMAIL
In order to access his global mail state, the client software must authenticate Fred to the repository; this is done via the DMSP login operation:
彼のグローバルなメール状態にアクセスするために、クライアントソフトウェアは倉庫にフレッドを認証しなければなりません。 DMSPログイン操作でこれをします:
600 (login) ["fred", "ajyr63ywg", "office-client",
FALSE, FALSE]
600(ログインします)["fred"、"ajyr63ywg"、誤って、誤った「オフィスクライアント」]
This tells the repository that Fred is logging in via "office-client", and that "office-client" is identified by an existing client object attached to Fred's user object. The second login block argument in an encrypted version of Fred's password. The final argument tells the repository that Fred's client is not operating in batch mode but rather in interactive mode.
これは、フレッドが「オフィスクライアント」を通してログインしていると倉庫に言います、そして、その「オフィスクライアント」はフレッドのユーザ物に取り付けられた既存のクライアント物によって特定されます。 フレッドのパスワードのコード化されたバージョンにおける2番目のログインブロック議論。 最終弁論は、フレッドのクライアントがバッチ・モード、しかし、むしろ会話型で働いていないと倉庫に言います。
Fred's authentication checks out, so the repository logs him in, acknowledging the login request with an OK block.
フレッドの認証がチェックアウトされるので、OKブロックによるログイン要求を承諾して、倉庫は彼にログインします。
Now that Fred is logged in, he wants to bring "office-client"'s local mail state up to date. To do this, the client program asks for an up-to-date list of mailboxes:
現在、フレッドがログインされて、彼が「オフィスクライアント」を持って来たがっているのは、最新に地方のメール状態です。 これをするために、クライアントプログラムはメールボックスの最新のリストを求めます:
800 (list-mailboxes) []
800 (リストメールボックス)[]
The repository replies with:
以下がある倉庫回答
801 (mailbox-list) [["main", 10, 1, 253],
["archive", 100, 0, 101]]
801 (メールボックスリスト)[「主である」、10、1、253] [「アーカイブ」、100、0、101]
This tells the client that there are two mailboxes, "main" and "archive". "Main" has 10 messages, one of which is unseen. The next incoming message will be assigned a UID of 253. "Archive", on the other hand, has 100 message, none of which are unseen. The next message sent to "archive" will be assigned the UID 101. There are no new mailboxes in the list (if there were, the client program would create them. On the other hand, if some mailboxes in the client's local list were not in the repository's list, the program would assume them deleted by another client and delete them locally as well).
これは、2個のメールボックス、「メイン」、および「アーカイブ」があるとクライアントに言います。 「メイン」には、10のメッセージがあります。その1つは見えないです。 253のUIDは次の入力メッセージに割り当てられるでしょう。 他方では、「アーカイブ」には、100メッセージがあります。そのいずれも見えなくはありません。 UID101は「アーカイブ」に送られた次のメッセージに割り当てられるでしょう。 リストにはどんな新しいメールボックスもありません。(あれば、クライアントプログラムはそれらを作成するでしょうに。 他方では、クライアントのローカルのリストのいくつかのメールボックスが倉庫のリストにないなら、プログラムは、別のクライアントによって削除されて、それらを仮定して、局所的にまた、それらを削除するでしょうに。).
To synchronize the client need only look at each mailbox's contents to see if (1) any new mail has arrived, or (2) if Fred changed any messages on one of his other two clients subsequent to "office-client"'s last connection to the repository.
(1) 何か新しいメールが到着したなら、クライアントを連動させるのは見るためには各メールボックスのコンテンツを見るだけでよいですか、フレッドが何か彼の「オフィスクライアント」における、その後の他の2人のクライアントのひとりに関するメッセージを変えたなら、(2)は倉庫への最後の接続です。
The client asks for any changed descriptors via the "get-changed-descriptors" operation. It requests at most ten changed descriptors since storage is very tight on "office-client".
クライアントは「変えられた記述子を得てください」という操作でどんな変えられた記述子も求めます。 それは、格納が「オフィスクライアント」に非常にきついので10が記述子を変えたよう高々要求します。
Clark & Lambert [Page 21]
クラークとランバート[21ページ]
RFC 984 May 1986 PCMAIL
RFC984 1986年5月のPCMAIL
1105 (get-changed-descriptors) ["main", 10]
1105(変えられた記述子を得てください)[「メイン」、10]
The repository responds with:
倉庫は以下で応じます。
1103 (descriptor-list) [[descriptor[
6,
[T T F F F F F F F F F F F F F F],
"Fred@borax",
"Joe@fab",
"Wed, 23 Jan 86 11:11 EST",
"tomorrow's meeting",
621,
10]]
[descriptor[
10,
[F T F F F F F F F F F F F F F F],
"Fred",
"Freds-secretary",
"Fri, 25 Jan 86 11:11 EST",
"Monthly progress report",
13211,
350]]
]
1103(記述子リスト)[記述子、[6、[T T F F F F F F F F F F F F F F] 621、" Fred@borax "、" Joe@fab "、「水曜日、1986年1月23日の東部標準時11時11分」が「明日は間に合う」10]、[記述子、[10、[F T F F F F F F F F F F F F F F]、「フレッド」、「Freds-秘書」、「金曜日、1986年1月25日の東部標準時11時11分」、「毎月の経過報告書」、13211、350]
The first descriptor in the list is one which Fred deleted on another client yesterday. "Office-client" marks the local version of the message as deleted. The second descriptor in the list is a new one. "Office-client" adds the descriptor to its local list. Since both changes have now been recorded locally, the descriptors can be reset:
リストにおける最初の記述子はフレッドが昨日別のクライアントで削除したものです。 「オフィスクライアント」は削除されるようにメッセージのローカルのバージョンをマークします。 リストにおける2番目の記述子は新しいものです。 「オフィスクライアント」はローカルのリストに記述子を追加します。 両方の変化が現在局所的に記録されて以来、記述子をリセットできます:
1106 (reset-descriptors) ["main", 2]
1106(リセット記述子)[「メイン」、2]
The repository clears each descriptor's update vector bit corresponding to "office-client"'s client object. "Main" has now been synchronized. The client now turns to Fred's "archive" mailbox and asks for the first ten changed descriptors.
倉庫は各記述子の「オフィスクライアント」において、対応するアップデートベクトルビットのクライアント物をきれいにします。 「メイン」は現在、連動しました。 クライアントは、今、フレッドの「アーカイブ」メールボックスに変わって、最初の10の変えられた記述子を求めます。
1105 (get-changed-descriptors) ["archive", 10]
1105(変えられた記述子を得てください)[「アーカイブ」、10]
The repository responds with
倉庫は応じます。
1103 (descriptor-list) []
1103(記述子リスト)[]
The zero-length list tells "office-client" that no descriptors have been changed in "archive" since its last synchronization. No new synchronization needs to be performed.
ゼロ・レングスリストは、最後の同期以来記述子が全く「アーカイブ」で変えられていないと「オフィスクライアント」に言います。 どんな新しい同期も、実行される必要がありません。
Clark & Lambert [Page 22]
クラークとランバート[22ページ]
RFC 984 May 1986 PCMAIL
RFC984 1986年5月のPCMAIL
Fred's client is now ready to pull over the new message so Fred can read it. The message is 320 lines long; there might not be sufficient storage on "office-client" to hold the new message. The client tries anyway:
フレッドがそれを読むことができるように、フレッドのクライアントは現在、新しいメッセージの上で引く準備ができています。 長い間、メッセージは320の線です。 十分な格納が新しいメッセージを保持する「オフィスクライアント」にないかもしれません。 クライアントはとにかく試みます:
1107 (fetch-message-text) ["main", 10]
1107(フェッチメッセージ・テキスト)[「メイン」、10]
The repository begins transmitting the message:
倉庫はメッセージを送り始めます:
1110 (message) ["From: Fred's-secretary",
"To: Fred",
"Subject: Monthly progress report",
"Date: Fri, 25 Jan 86 11:11 EST",
"",
"Dear Fred,",
"Here is this month's progress report",
...
]
1110(メッセージ)[、「From: フレッドのもの秘書」「To: フレッド」、「Subject: Monthly経過報告書」、「日付: 金曜日、1986年1月25日の東部標準時11時11分」、「「「親愛なるフレッド」、「ここに、今月の経過報告書がある」…]、」
Halfway through the message transmission, "office-client" runs out of disk space. Because all DMSP operations are defined to be atomic, the portion of the message already transmitted is destroyed locally and the operation fails. "Office-client" informs Fred that the message cannot be pulled over because of a lack of disk space. The synchronization process is now finished and Fred's client logs out.
途中で、メッセージ送信で、「オフィスクライアント」は椎間腔を使い果たします。 すべてのDMSP操作が原子であるために定義されるので、既に送られたメッセージの部分は局所的に破壊されます、そして、操作は失敗します。 「オフィスクライアント」は、椎間腔の不足のためにメッセージを引くことができないことをフレッドに知らせます。 同期の過程は現在終わっています、そして、フレッドのクライアントはログアウトします。
601 (logout) []
601(ログアウトします)[]
The repository does any housecleaning it needs to do, acknowledges the logout request, and closes the USP connection.
ログアウトしてください。倉庫がそれがする必要があるどんなそうじもする、承認、USP接続を要求して、終えます。
7. A Current Pcmail Implementation
7. 現在のPcmail実現
The following section briefly describes a current implementation of Pcmail that services a small community of users. The Pcmail repository runs under UNIX on a DEC VAX-750 connected to the Internet. The clients are IBM PCs, XTs, and ATs. The network software that communicates with the repository allows only "batch-mode" operation. Users make local state changes, which are queued until the client connects to the repository. At that time, the changes are performed and the local and global states synchronized. The client then disconnects from the repository.
以下のセクションは簡潔にユーザの小規模地域社会にサービスを提供するPcmailの現在の実現について説明します。 Pcmail倉庫はインターネットに接続されたDEC VAX-750でUNIXで実行されます。 クライアントは、IBM PCと、XTsと、ATsです。 倉庫で交信するネットワークソフトウェアは「バッチ・モード」操作だけを許します。 ユーザは地方の州の変更を行います。(クライアントが倉庫に接続するまで、変更は列に並ばせられます)。 その時、変化は実行されました、そして、地方の、そして、グローバルな州は連動しました。 そして、クライアントは倉庫から連絡を断ちます。
Users access and modify their local mail state via a user interface program. The program uses windows and a full-screen mode of operation. Users are given a rich variety of commands to operate on
ユーザは、ユーザーインタフェースプログラムを通して地元のメール状態にアクセスして、変更します。 プログラムは窓とフルスクリーン運転モードを使用します。 ユーザは作動するコマンドの与えられたa豊かなバラエティーです。
Clark & Lambert [Page 23]
クラークとランバート[23ページ]
RFC 984 May 1986 PCMAIL
RFC984 1986年5月のPCMAIL
individual messages as well as mailboxes. The interface allows use of any text editor to compose messages, and adds features of its own to make RFC-822-style header composition easier.
メールボックスと同様に個々のメッセージ。 インタフェースは、どんなテキストエディタの使用もメッセージを構成するのを許容して、それ自身のものがRFC822スタイルヘッダー構成をより簡単にする特徴を言い足します。
Synchronization and the processing of queued changes is performed by a separate program, which the user runs whenever he wishes. The program takes any actions queued while operating the user interface, and converts them into DMSP operations. All queued changes are made before any synchronization is performed.
列に並ばせられた変化の同期と処理は別々のプログラムで実行されます。(願っているときはいつも、ユーザはそれを動かします)。 プログラムは、ユーザーインタフェースを操作している間に列に並ばせられたどんな行動も取って、DMSP操作にそれらを変換します。 どんな同期も実行される前にすべての列に並ばせられた変更が行われます。
The limitation of client operation to batch mode was made for the following reasons: first, the implementation is slanted toward use of portable computers as clients. These computers are rarely connected to the network, making interactive mode unnecessary. Those clients that are constantly connected to the network run slightly less efficiently than they could (since users must make changes locally and then run the action-processing/synchronization program, rather than simply making changes interactively).
以下の理由でバッチ・モードへのクライアント操作の制限をしました: まず最初に、実現はクライアントとしてポータブル・コンピュータの使用に向かって傾斜しています。 会話型を不要にして、これらのコンピュータはめったにネットワークに接続されません。 絶えず彼らよりわずかに効率的でなくネットワーク走行に接続されるそれらのクライアントはそうすることができました(ユーザが局所的に変更を行って、次に、単にインタラクティブに変更を行うよりむしろ動作処理/同期プログラムを動かさなければならないので)。
Another important reason for limiting operation to batch mode is that it allows a very simple locking scheme to prevent problems raised by concurrent state updates. A user may have several clients; it is therefore likely that the repository could get into a variety of inconsistent states as different clients try to change the repository's global mail state at the same time. To prevent these inconsistencies, a user's mail state is locked as soon as a client connects to the repository. The lock is released when the client disconnects from the repository. This locking scheme is simple to implement, but makes interactive-mode operation very cumbersome: if a user remains constantly connected to the network (i.e. in interactive mode), the repository would be unavailable to any of the user's other clients for an unacceptable length of time.
操作をバッチ・モードに制限する別の重要な理由は非常に簡単なロック計画がそれで同時発生の州のアップデートで提起された問題を防ぐことができるということです。 ユーザには、数人のクライアントがいるかもしれません。 したがって、異なったクライアントが同時に倉庫のグローバルなメール状態を変えようとするとき、倉庫はさまざまな矛盾した州に入るかもしれなそうです。 これらの矛盾を防ぐために、クライアントが倉庫に接続するとすぐに、ユーザのメール状態はロックされます。 クライアントが倉庫から連絡を断つとき、錠はリリースされます。 このロック計画で、実行するのが簡単ですが、会話型操作は非常に厄介になります: ユーザが絶えずネットワーク(すなわち、会話型による)に関連していたままで残っているなら、容認できない長さの時間のユーザの他のクライアントのいずれにも、倉庫は入手できないでしょう。
8. Conclusions
8. 結論
Pcmail is now used by a small community of people at the MIT Laboratory for Computer Science. The repository design works well, providing a fairly efficient means of storing and maintaining mail state for several users. Members of another research group at LCS are currently working on a replicated, scaleable version of the repository designed to support a very large community of users with high availability. This repository also uses DMSP and has successfully communicated with clients that use the current repository implementation. DMSP therefore seems to be useable over several flavors of repository design. The clients, being PCs, are unfortunately very limited in the way of resources, making local mail state manipulation difficult at times. Synchronization is also
Pcmailは現在、MITコンピュータサイエンス研究所で人々の小規模地域社会によって使用されます。 数人のユーザのためにメール状態を格納して、維持するかなり効率的な手段を提供して、倉庫デザインはうまくいきます。 LCSの別の研究グループのメンバーは現在、高い有用性でユーザの非常に大きい共同体を支持するように設計された倉庫の模写されて、スケーラブルなバージョンに取り組んでいます。 この倉庫も、DMSPを使用して、首尾よく現在の倉庫実現を使用するクライアントと交信しました。 したがって、DMSPは、倉庫デザインのいくつかの風味の上でuseableであるように思えます。 PCであり残念ながら、クライアントはリソースの方法で非常に限られています、時には地方のメール州の操作を難しくして。 また、同期はそうです。
Clark & Lambert [Page 24]
クラークとランバート[24ページ]
RFC 984 May 1986 PCMAIL
RFC984 1986年5月のPCMAIL
relatively time consuming due to the low performance of the PCs. The "batch-mode" of client operation is very useful for portable computers that spend a large percentage of their time unplugged and away from a network. It is somewhat less useful for the majority of the clients, which are always connected to the network and could make good use of an "interactive-mode" state manipulation.
PCの低性能のために比較的時間がかかります。 クライアント操作の「バッチ・モード」は非常にそれらの時間アンプラグドの大きな割合とネットワークから遠くで費やされるポータブル・コンピュータの役に立ちます。 それは、いくらかいつもネットワークに接続されるクライアントの大部分の役に立たないで、有効に「会話型」州の操作を利用するかもしれません。
Clark & Lambert [Page 25]
クラークとランバート[25ページ]
RFC 984 May 1986 PCMAIL
RFC984 1986年5月のPCMAIL
I. DMSP Protocol Specification
I. DMSPプロトコル仕様
Following is a list of DMSP block types and DMSP operations by object type. Again, "=>" marks blocks flowing from client to repository; "<=" marks blocks flowing from repository to client.
以下に、オブジェクト・タイプによるDMSPゴシック体とDMSP操作のリストがあります。 一方、「=>」はクライアントから倉庫まで流れるブロックを示します。 「<=」は倉庫からクライアントまで流れるブロックを示します。
General operations:
一般操作:
=> or <= 503 (abort-request) [why:str]
(no acknowledgement)
=>か<=503(アボート要求)[なぜ: str](承認がありません)
=> 504 (start-debug) []
<= 500 (ok) [] |
501 (failure) [why:str]
=>504(スタートデバッグ)[]<は500(OK)[]と等しいです。| 501 (失敗)[なぜ: str]
=> 505 (end-debug) []
<= 500 (ok) []
=>505(終わりデバッグ)[]<=500(OK)[]
=> 506 (send-version) [version:card]
<= 500 (ok) [] |
501 (failure) [why:str]
=>506(バージョンを発信させている)[バージョン: カード]<は500(OK)[]と等しいです。| 501 (失敗)[なぜ: str]
=> 507 (log-message) [message:str]
<= 500 (ok) [] |
501 (failure) [why:str]
=>507(ログメッセージ)[メッセージ: str]<は500(OK)[]と等しいです。| 501 (失敗)[なぜ: str]
=> 508 (send-message) [message:seq[str]]
<= 500 (ok) [] |
501 (failure) [why:str]
=>508(メッセージを発信させている)[メッセージ: seq[str]]<は500(OK)[]と等しいです。| 501 (失敗)[なぜ: str]
User operations:
ユーザ操作:
=> 600 (login) [name:str, password:str,
client:str, create-client-object?:bool
batch-mode-flag:bool]
<= 500 (ok) [] |
501 (failure) [why:str] |
705 (force-client-reset) []
=[クライアント: 名前: str、パスワード: str、str、クライアント物を作成してください--: boolバッチモード旗: bool]という>600(ログインする)<は500(OK)[]と等しいです。| 501 (失敗)[なぜ: str]| 705 (力のクライアントリセット)[]
=> 601 (logout) []
<= 500 (ok) []
=>601(ログアウトする)[]<=500(OK)[]
=> 602 (add-user) [name:str, password:str]
<= 500 (ok) [] |
501 (failure) [why:str]
=>602(ユーザを加えている)[名前: str、パスワード: str]<は500(OK)[]と等しいです。| 501 (失敗)[なぜ: str]
Clark & Lambert [Page 26]
クラークとランバート[26ページ]
RFC 984 May 1986 PCMAIL
RFC984 1986年5月のPCMAIL
=> 603 (remove-user) [user:str]
<= 500 (ok) [] |
501 (failure) [why:str]
=>603(ユーザを外している)[ユーザ: str]<は500(OK)[]と等しいです。| 501 (失敗)[なぜ: str]
=> 604 (set-password) [old:str, new:str]
<= 500 (ok) [] |
501 (failure) [why:str]
=>604(設定パスワードの)[strであって、新しい老人: str]<は500(OK)[]と等しいです。| 501 (失敗)[なぜ: str]
Client operations:
クライアント操作:
=> 700 (list-clients) []
<= 701 (client-list) [client-list:seq[
rec[name:str], status:card]]
=>700(リストクライアント)[]<=701(顧客リスト)[顧客リスト: seq[状態: rec[名前: str]、カード]]
=> 702 (add-client) [client:str]
<= 500 (ok) [] |
501 (failure) [why:str]
=>702(クライアントを加えている)[クライアント: str]<は500(OK)[]と等しいです。| 501 (失敗)[なぜ: str]
=> 703 (remove-client) [client:str]
<= 500 (ok) [] |
501 (failure) [why:str]
=>703(クライアントを外している)[クライアント: str]<は500(OK)[]と等しいです。| 501 (失敗)[なぜ: str]
=> 704 (reset-client) [client:str]
<= 500 (ok) [] |
501 (failure) [why:str]
=>704(リセットクライアント)[クライアント: str]<は500(OK)[]と等しいです。| 501 (失敗)[なぜ: str]
Mailbox operations:
メールボックス操作:
=> 800 (list-mailboxes) []
<= 801 (mailbox-list) [mailbox-list:seq[
rec[mailbox:str,
next-uid:lcard,
num-msgs:card,
num-unseen-msgs:card]]]
=>800(リストメールボックス)[]<=801(メールボックスリスト)[メールボックスリスト: seq[rec[メールボックス: 次のuid: str、lcard、num-msgs: numの見えないmsgs: カード、カード]]]
=> 802 (add-mailbox) [mailbox:str]
<= 500 (ok) [] |
501 (failure) [why:str]
=>802(メールボックスを加えている)[メールボックス: str]<は500(OK)[]と等しいです。| 501 (失敗)[なぜ: str]
=> 803 (remove-mailbox) [mailbox:str]
<= 500 (ok) [] |
501 (failure) [why:str]
=>803(メールボックスを取り外している)[メールボックス: str]<は500(OK)[]と等しいです。| 501 (失敗)[なぜ: str]
=> 808 (expunge-mailbox) [mailbox:str]
<= 500 (ok) [] |
501 (failure) [why:str]
=>808(メールボックスを梢消している)[メールボックス: str]<は500(OK)[]と等しいです。| 501 (失敗)[なぜ: str]
Clark & Lambert [Page 27]
クラークとランバート[27ページ]
RFC 984 May 1986 PCMAIL
RFC984 1986年5月のPCMAIL
=> 809 (reset-mailbox) [mailbox:str]
<= 500 (ok) [] |
501 (failure) [why:str]
=>809(リセットメールボックス)[メールボックス: str]<は500(OK)[]と等しいです。| 501 (失敗)[なぜ: str]
Address operations:
操作を記述してください:
=> 804 (list-addresses) [mailbox:str]
<= 501 (failure) [why:str] |
805 (address-list) [address-list:seq[str]]
=>804(リストアドレス)[メールボックス: str]<=501(失敗)[なぜ: str]| 805 (住所録)[住所録: seq[str]]
=> 806 (add-address) [mailbox:str, address:str]
<= 500 (ok) [] |
501 (failure) [why:str]
=>806(アドレスを加えている)[メールボックス: アドレス: str、str]<は500(OK)[]と等しいです。| 501 (失敗)[なぜ: str]
=> 807 (remove-address) [mailbox:str, address:str]
<= 500 (ok) [] |
501 (failure) [why:str]
=>807(アドレスを取り外している)[メールボックス: アドレス: str、str]<は500(OK)[]と等しいです。| 501 (失敗)[なぜ: str]
Message operations:
メッセージ操作:
=> 1100 (get-descriptor-flags) [mailbox:str, uid:lcard]
<= 1101 (descriptor-flags) [flags:seq[bool]] |
501 (failure) [why:str]
=>1100(記述子旗を手に入れてください)[メールボックス: str、uid: lcard]<=1101(記述子旗)[旗: seq[bool]]| 501 (失敗)[なぜ: str]
=> 1102 (get-descriptors) [mailbox:str,
low-uid:lcard,
high-uid:lcard]
<= 501 (failure) [why:str] |
1103 (descriptor-list) [descriptor-list:seq[
ch[
expunged[uid:lcard],
descriptor[rec[uid:lcard,
flags:seq[bool],
from-field:str,
to-field:str,
date-field:str,
subject-field:str,
nun-bytes:lcard,
num-lines:lcard]
]]]]
=>1102(記述子を得ている)[メールボックス: str、低いuid: lcard、高いuid: lcard]<=501(失敗)[なぜ: str]| 1103(記述子リスト)[記述子リスト: seq[ch[[uid: lcard]、記述子[rec[旗: 分野からのuid: lcard、seq[bool]: 分野へのstr: str、: str、受けることがある分野を日付でさばいてください: str尼僧バイト: (lcard)は: lcardをnum裏打ちする]]を梢消します]]]
Clark & Lambert [Page 28]
クラークとランバート[28ページ]
RFC 984 May 1986 PCMAIL
RFC984 1986年5月のPCMAIL
=> 1105 (get-changed-descriptors) [mailbox:str,
max-to-send:card]
<= 501 (failure) [why:str] |
1103 (descriptor-list) [descriptor-list:seq[
ch[
expunged[uid:lcard],
descriptor[rec[uid:lcard,
flags:seq[bool],
from-field:str,
to-field:str,
date-field:str,
subject-field:str,
num-bytes:lcard,
num-lines:lcard]
]]]]
=>1105(変えられた記述子を得てください)[メールボックス: str、送る最大: カード]<=501(失敗)[なぜ: str]| 1103(記述子リスト)[記述子リスト: seq[ch[[uid: lcard]、記述子[rec[旗: 分野からのuid: lcard、seq[bool]: 分野へのstr: str、: str、受けることがある分野を日付でさばいてください: str num-バイト: (lcard)は: lcardをnum裏打ちする]]を梢消します]]]
=> 1106 (reset-changed-descriptors) [
mailbox:str,
start-uid:lcard,
end-uid:lcard]
<= 500 (ok) [] |
501 (failure) [why:str]
=>1106(リセットは記述子を変えました)[メールボックス: str、始め-uid: lcard、終わり-uid: lcard]<は500(OK)[]と等しいです。| 501 (失敗)[なぜ: str]
=> 1107 (get-message-text) [mailbox:str,
uid:lcard]
<= 501 (failure) [why:str] |
1110 (message) [message:seq[str]]
=>1107(メッセージ・テキストを得ている)[メールボックス: str、uid: lcard]<=501(失敗)[なぜ: str]| 1110(メッセージ)[メッセージ: seq[str]]
=> 1108 (print-message) [mailbox:str,
uid:lcard,
printer-name:str]
<= 500 (ok) [] |
501 (failure) [why:str]
=>1108(印刷メッセージ)[メールボックス: str、uid: プリンタ名: lcard、str]<は500(OK)[]と等しいです。| 501 (失敗)[なぜ: str]
=> 1109 (set-flag) [mailbox:str,
uid:lcard,
flag-number:card,
flag-setting:bool]
<= 500 (ok) [] |
501 (failure) [why:str]
=>1109(セット旗)[メールボックス: str、uid: 旗設定: lcard、旗番号: カード、bool]<は500(OK)[]と等しいです。| 501 (失敗)[なぜ: str]
=> 1111 copy-message[source-mailbox:str,
target-mailbox:str,
source-uid:lcard]
<= 500 (ok) [] |
501 (failure) [why:str]
=1111年の>コピーメッセージ[ソースメールボックス: str、目標メールボックス: str、ソース-uid: lcard]<は500(OK)[]と等しいです。| 501 (失敗)[なぜ: str]
Clark & Lambert [Page 29]
クラークとランバート[29ページ]
RFC 984 May 1986 PCMAIL
RFC984 1986年5月のPCMAIL
DMSP block types by number
数に従ったDMSPゴシック体
General block types
一般ゴシック体
ok 500
failure 501
abort-request 503
start-debug 504
end-debug 505
send-version 506
log-message 507
send-message 508
503スタートデバッグ504がメッセージを発信させる状態でバージョンを発信させている505 506ログメッセージ507を終わりでデバッグするという間違いない500失敗501アボート要求508
User operation block types
ユーザ操作ゴシック体
login 600
logout 601
add-user 602
remove-user 603
set-password 604
ログイン600がログアウトする、ユーザを加えている601 602ユーザを外している603セットパスワード604
Client operation block types
クライアント操作ゴシック体
list-clients 700
client-list 701
add-clien 702
remove-client 703
reset-client 704
force-client-reset 705
clienを加えているリストクライアント700顧客リスト701 702クライアントを外している703 704力のクライアントリセットリセットクライアント705
Mailbox operation block types
メールボックス操作ゴシック体
list-mailboxes 800
mailbox-list 801
add-mailbox 802
remove-mailbox 803
expunge-mailbox 808
reset-mailbox 809
メールボックスを取り外しているリストメールボックスの801メールボックスを加えている802 803メールボックスを梢消している808リセットメールボックス800メールボックスリスト809
Clark & Lambert [Page 30]
クラークとランバート[30ページ]
RFC 984 May 1986 PCMAIL
RFC984 1986年5月のPCMAIL
Address operation block types
アドレス操作ゴシック体
list-addresses 804
address-list 805
add-address 806
remove-address 807
アドレスを取り外してアドレスを加えている804住所録805 806をリストで記述する、807
Message operation block types
メッセージ操作ゴシック体
get-descriptor-flags 1100
descriptor-flags 1101
get-descriptors 1102
descriptor-list 1103
get-changed-descriptors 1105
reset-changed-descriptors 1106
get-message-text 1107
print-message 1108
set-flag 1109
message 1110
copy-message 1111
記述子旗を手に入れている1100 1101年の1102年の1103年の1105年の1106年の1107年の1108年の1109年のリセットが記述子を変えている記述子を得ている変えられた記述子を得ているメッセージ・テキストを得ている記述子旗の印刷メッセージセット旗の記述子リストメッセージ1110コピーメッセージ1111
Clark & Lambert [Page 31]
クラークとランバート[31ページ]
一覧
スポンサーリンク
