RFC1056 日本語訳
1056 PCMAIL: A distributed mail system for personal computers. M.L.Lambert. June 1988. (Format: TXT=85368 bytes) (Obsoletes RFC0993) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group M. Lambert Request for Comments: 1056 MIT Obsoletes: RFC-993 June 1988
コメントを求めるワーキンググループM.ランバート要求をネットワークでつないでください: 1056 MITは以下を時代遅れにします。 RFC-993 1988年6月
PCMAIL: A Distributed Mail System for Personal Computers
PCMAIL: パーソナルコンピュータの分配されたメールシステム
Table of Contents
目次
1. Status of this Document 1
2. Introduction 2
3. Repository architecture 4
3.1. Management of user mail state 5
3.2. Repository-to-RFC-822 name translation 7
4. Communication between repository and client: DMSP 8
4.1. DMSP commands 8
4.2. DMSP responses 8
4.3. DMSP sessions 11
4.4. General operations 11
4.5. User operations 12
4.6. Client operations 13
4.7. Mailbox operations 14
4.8. Address operations 15
4.9. Subscription operations 15
4.10. Message operations 16
5. Client Architecture 18
5.1. Multiple clients 18
5.2. Synchronization 18
5.3. Batch operation versus interactive operation 20
5.4. Message summaries 20
6. Typical interactive-style client-repository interaction 21
7. A current Pcmail implementation 25
7.1. IBM PC client code 25
7.2. UNIX client code 26
7.3. Repository code 26
8. Conclusions 26
I. DMSP Protocol Specification 28
II. Operations by name 37
III. Responses by number 38
1. このDocument1 2の状態。 序論2 3。 倉庫アーキテクチャ4 3.1。 ユーザメールの経営者側は3.2に5を述べます。 倉庫からRFC-822は翻訳を7 4と命名します。 倉庫とクライアントとのコミュニケーション: DMSP8 4.1。 DMSPは4.2に8を命令します。 DMSP応答8 4.3。 DMSPセッション11 4.4。 一般操作11 4.5。 ユーザ操作12 4.6。 クライアント操作13 4.7。 メールボックス操作14 4.8。 操作15 4.9を扱ってください。 購読操作15 4.10。 メッセージ操作16 5。 クライアントアーキテクチャ18 5.1。 複数のクライアント18 5.2。 同期18 5.3。 バッチ運転対対話的な操作20 5.4 メッセージ概要20 6。 典型的な対話的なスタイルクライアント倉庫相互作用21 7。 現在のPcmail実装25 7.1。 IBM PCクライアントコード25 7.2。 UNIXクライアントコード26 7.3。 倉庫コード26 8。 結論26I.DMSPは仕様28IIについて議定書の中で述べます。 名前37IIIによる操作。 No.38に従った応答
1. Status of this Memo
1. このMemoの状態
This RFC is a discussion of the Pcmail workstation based distributed mail system. It is identical to the discussion in RFC-993, save that a new, much simpler mail transport protocol is described. The new transport protocol is the result of continued research into ease of protocol implementation and use issues. Distribution of this memo is unlimited.
このRFCはPcmailワークステーションに基づいている分配されたメールシステムの議論です。 新しくて、はるかに簡単なメールトランスポート・プロトコルが説明されるのは、RFC-993での議論と同じであり、節約されます。 新しいトランスポート・プロトコルはプロトコル実装の容易さの継続的な研究の結果であり、使用は問題です。 このメモの分配は無制限です。
Lambert [Page 1] RFC 1056 PCMAIL June 1988
ランバート[1ページ]RFC1056PCMAIL1988年6月
2. Introduction
2. 序論
Pcmail is a distributed mail system providing mail service to an arbitrary number of users, each of whom owns one or more workstations. Pcmail's motivation is to provide very flexible mail service to a wide variety of different workstations, ranging in power from small, resource-limited machines like IBM PCs to resource-rich (where "resources" are primarily processor speed and disk space) machines like Suns or Microvaxes. It attempts to provide limited service to resource-limited workstations while still providing full service to resource-rich machines. It is intended to work well with machines only infrequently connected to a network as well as machines permanently connected to a network. It is also designed to offer diskless workstations full mail service.
Pcmailはそのそれぞれが1台以上のワークステーションを所有しているユーザの特殊活字の数字に対するメールサービスを提供する分配されたメールシステムです。 Pcmailの動機はさまざまな異なったワークステーションに対する非常にフレキシブルなメールサービスを提供することです、IBM PCのような小さくて、リソースで限られたマシンから資源に富んだ(「リソース」が主としてプロセッサ速度と椎間腔であるところ)サンズやMicrovaxesのようなマシンまでパワーのねらいを定めて。 それは、まだ資源に富んだマシンにフルサービスを供給している間、リソースで限られたワークステーションに対する限られたサービスを提供するのを試みます。 マシンがネットワークにまれに接続されるだけであり、マシンが永久にネットワークに接続される状態でうまくいくのは意図しています。 また、それは、完全なメールサービスをディスクレスワークステーションに提供するように設計されています。
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.
システムは2つの半分に分割されます。 1番目は「倉庫」と呼ばれる単一体から成ります。 倉庫は入って来るメールのためのストレージセンターです。 Pcmailユーザのためのメールはインターネットから他の倉庫ユーザから外部的に内部的に到着できます。 また、倉庫は安定したコピーの各ユーザのメール状態を維持します(これは今後ユーザの「グローバルなメール状態」と呼ばれるでしょう)。 したがって、通常、倉庫は多量のディスクストレージがあるコンピュータです。
The second half of Pcmail consists of one or more "clients". Each Pcmail user may have an arbitrary number of clients, typically single-user workstations. 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". It is assumed that clients, possibly being small personal computers, 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ユーザには、クライアント、通常シングルユーザーワークステーションの特殊活字の数字があるかもしれません。 クライアントはネットワークの上でユーザのグローバルなメール状態にアクセスする好意的な手段をユーザに提供します。 倉庫とユーザのクライアントとの相互作用をより効率的にするように、「地方のメール状態」は、各クライアントが地方のコピーのユーザのグローバルなメール状態を維持すると呼びました。 ことによると小さいパーソナルコンピュータでありクライアントがいつも、ネットワーク(そしてしたがって、倉庫のグローバルなメール状態に)に近づく手段を持っているかもしれないというわけではないと思われます。 これは、地方の、そして、グローバルなメール州が絶えず同じでないかもしれないことを意味します、地方の、そして、グローバルなメール州の間の同期を必要にして。
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 failure-atomic (that is, they are
guaranteed either to succeed completely, or leave the user's mail
DistributedメールSystemプロトコル(DMSP)でクライアントは倉庫で交信します。 このプロトコルのための仕様は付録A.に載っています。したがって、倉庫はメール端サイトと貯蔵場所に加えてDMSPサーバです。 DMSPはメールの完全な操作操作(「メッセージを送っ」て、「メッセージを削除し」て、「メッセージを印刷しますなど」)を提供します。 また、DMSPは、ユーザのグローバルなメール州と彼のクライアントの地方のメール州の間の簡単な同期を許容するために特殊作戦を提供します。 DMSP操作がユーザのメール状態に影響する方法に特別の注意を向けました。 すべてのDMSP操作が失敗原子です。(すなわち、それらが完全に成功するように保証される、ユーザのメールを残してください。
Lambert [Page 2] RFC 1056 PCMAIL June 1988
ランバート[2ページ]RFC1056PCMAIL1988年6月
state unchanged ). A client can be abruptly disconnected from the repository without leaving inconsistent or damaged mail states.
州の変わりのない、) 矛盾したか破損しているメールを州に残さないで、倉庫からクライアントから突然に切断することができます。
Pcmail's design has been directed by the characteristics of currently available workstations. Some workstations are fairly portable, and can be packed up and moved in the back seat of an automobile. A few are truly portable--about the size of a briefcase--and battery- powered. Some workstations have constant access to a high-speed local-area network; pcmail should allow for "on-line" mail delivery for these machines while at the same time providing "batch" mail delivery for other workstations that are not always connected to a network. Portable and semi-portable workstations tend to be resource-poor. A typical IBM 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 must be able to provide machines like this with adequate mail service without hampering its performance on more resource-rich workstations. Finally, all workstations have some common characteristics that Pcmail should take advantage of. For instance, workstations are fairly inexpensive compared to the various time-shared systems that most people use for mail service. This means that people may own more than one workstation, perhaps putting a Microvax in an office and an IBM PC at home.
Pcmailのデザインは現在利用可能なワークステーションの特性によって指示されました。 自動車の後部座席でいくつかのワークステーションは、かなり携帯用であり、詰め込んで、動かすことができます。 本当に、いくつかは携帯用であり(およそブリーフケースのサイズ)、バッテリーは動力付きです。 いくつかのワークステーションが高速ローカル・エリア・ネットワークに一定のアクセスを持っています。 pcmailは同時にいつもネットワークに接続されるというわけではない他のワークステーションのための「バッチ」郵便配達を提供する間、これらのマシンのための「オンライン」の郵便配達を考慮するはずです。 携帯用の、そして、準携帯用のワークステーションは、資源の乏しい傾向があります。 典型的なIBM PCは主記憶装置に少量(通常1メガバイト未満)少ししか大容量記憶(恐らく360キロバイトのデータにアクセスできるフロッピーディスクドライブ)の方法で持っていません。 より資源に富んだワークステーションに関する性能を妨げないで、Pcmailは適切なメールサービスをこのようなマシンに提供できなければなりません。 最終的に、すべてのワークステーションには、Pcmailが利用するはずであるいくつかの共通する特徴があります。 例えば、ほとんどの人々がメールサービスに使用する様々な時分割されたシステムと比べて、ワークステーションはかなり安価です。 これは、人々が1台以上のワークステーションを所有するかもしれないことを意味します、恐らくホームでオフィスとIBM PCにMicrovaxを入れて。
Pcmail's design reflects the differing characteristics of the various workstations. Since one person can own several workstations, Pcmail allows users multiple access points to their mail state. Each Pcmail user can have several client workstations, each of which can access the user's mail by communicating with the repository over a network. The clients all maintain local copies of the user's global mail state, and synchronize the local and global states using DMSP.
Pcmailのデザインは様々なワークステーションの異なった特性を反映します。 1人の人がいくつかのワークステーションを所有できるので、Pcmailはそれらのメール状態への複数のアクセスポイントをユーザに許容します。 それぞれのPcmailユーザはいくつかのクライアントワークステーションを持つことができます。ネットワークの上で倉庫で交信することによって、それはそれぞれユーザのメールにアクセスできます。 クライアントは、地方のコピーのユーザのグローバルなメール状態を皆、維持して、DMSPを使用することで地方の、そして、グローバルな州を連動させます。
It is also possible that some workstations 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 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 locally. When the client is next connected to the repository, the changes are executed, and the client's local mail state is synchronized with the repository's global mail state.
また、いくつかのワークステーションがネットワークにまれに接続されるだけであるのも(その結果、倉庫で交信できてください)、可能です。 したがって、Pcmailデザインは倉庫とクライアントとのコミュニケーションの2つのモードを許容します。 クライアントがいつもネットワークに接続されるとき、「会話型」は使用されています。 また、すぐにクライアントの地方のメール状態へのどんな変更も倉庫のグローバルなメール状態にします、そして、すぐに、倉庫からクライアントまでどんな入って来るメールも送ります。 「バッチ・モード」は珍しいアクセスを倉庫に持っているクライアントによって使用されます。 ユーザはクライアントの地方のメール状態を操って、待ち行列は変化です。局所的に。 クライアントが倉庫に接続されていた状態で次であるときに、変化は実行されます、そして、クライアントの地方のメール状態は倉庫のグローバルなメール状態と同期します。
Finally, the Pcmail design minimizes the effect of using a resource- poor workstation as a client. Mail messages are split into two
最終的に、Pcmailデザインはクライアントとしてリソースの不十分なワークステーションを使用するという効果を最小にします。 メール・メッセージは2に分けられます。
Lambert [Page 3] RFC 1056 PCMAIL June 1988
ランバート[3ページ]RFC1056PCMAIL1988年6月
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 usually hold a complete set of descriptors, thus providing the user with at least a summary of his mail state. For clients with extremely limited resources, Pcmail allows the storage of partial sets of descriptors. Although this means the user does not have a complete local mail state, he can at least look at summaries of some messages. In the cases where the client cannot immediately store message bodies, it can always pull them over from the repository as storage becomes available.
部品: 「記述子」と「ボディー。」 記述子は長さ(通常およそ100バイト)が実際のメッセージ長から独立しているカプセルメッセージ概要です。 ボディーはRFC-822の標準のメッセージヘッダーを含む実際のメッセージ・テキストです。 クライアントには完全なセットのメッセージを保持できるくらいのストレージがないかもしれない間、通常、完全なセットの記述子を保持できます、その結果、少なくとも彼のメール状態の概要をユーザに提供します。 非常に限られたリソースをもっているクライアントに関しては、Pcmailは部分的なセットの記述子のストレージを許します。 これは、ユーザには完全な地方のメール状態がないことを意味しますが、彼はいくつかのメッセージの概要を少なくとも見ることができます。 クライアントがすぐにメッセージ本体を保存できない場合では、ストレージが利用可能になるのに従って、それは倉庫からそれらをいつも引くことができます。
The remainder of this document is broken up into sections discussing the following:
このドキュメントの残りは以下について論ずるセクションに終えられます:
- The repository architecture
- 倉庫アーキテクチャ
- DMSP, its operations, and motivation for its design
- デザインに関するDMSP、操作、および動機
- The client architecture
- クライアントアーキテクチャ
- A typical DMSP session between the repository and a
client
- 倉庫とクライアントとの典型的なDMSPセッション
- The current Pcmail implementation
- 現在のPcmail実装
- Appendices describing the DMSP protocol in detail
- 詳細にDMSPプロトコルについて説明する付録
3. Repository architecture
3. 倉庫アーキテクチャ
A typical machine running repository code has a relatively powerful processor and a large amount of disk storage. It must also be a permanent network site, for two reasons. First, clients communicate with the repository over a network, and rely on the repository's being available at any time. Second, people sending mail to repository users rely on the repository's being available to receive mail at any time.
典型的なマシン実行倉庫コードには、比較的強力なプロセッサと多量のディスクストレージがあります。 また、2つの理由でそれは永久的なネットワークサイトであるに違いありません。 まず最初に、クライアントは、ネットワークの上で倉庫で交信して、倉庫のいつでも利用可能な存在に依存します。 2番目に、倉庫ユーザにメールを送る人々が倉庫のいつでもメールを受け取るために利用可能な存在に依存します。
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. Since a large category of electronic mail is represented by bulletin boards (bboards), the repository should efficiently manage bboard mail, using a minimum of storage to store
倉庫はいくつかのタスクを実行しなければなりません。 まず最初に、最も重要に、倉庫は効率的に潜在的に多くのユーザと彼らのメール州を経営しなければなりません。 複数のクライアントがグローバルなメール状態にアクセスして、地元のメール州をグローバルな状態に連動させるのを簡単にする方法でメールを確かに保存しなければなりません。 掲示板(bboards)によって電子メールの大きいカテゴリが表されるので、倉庫は効率的にbboardメールを管理するはずです、最小保存するストレージを使用して
Lambert [Page 4] RFC 1056 PCMAIL June 1988
ランバート[4ページ]RFC1056PCMAIL1988年6月
bboard messages in a manner that still allows any user subscribing to the bboard to read the mail. 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.
bboardに加入するどんなユーザもまだメールを読むことができる方法によるbboardメッセージ。 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 associated with 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, a list of "subscription objects", and a list of "mailbox objects".
Pcmailは世界をユーザの共同体に分割します。 それぞれのユーザはユーザオブジェクトに関連しています。 ユーザオブジェクトはユニークな名前、パスワード(ユーザのクライアントがグローバルなメール状態を操る前に倉庫に自分たちを認証するのに使用する)、ユーザのものであるそれらのクライアントについて説明する「クライアントオブジェクト」のリスト、「購読オブジェクト」のリスト、および「メールボックスオブジェクト」のリストから成ります。
A client object consists of a unique name and a status. A user 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 client an "update list" of message state changes which have occurred since the client's last synchronization.
クライアントオブジェクトはユニークな名前と状態から成ります。 ユーザは彼が所有している各クライアントあたり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 repository implementation). When a previously-inactive client does connect to the repository, the repository notifies the client that it has been inactive for some time and should "reset" itself. Resetting a client has the effect of placing every message in every mailbox onto the client's update list. This allows the client to get a fresh global mail state from the repository when it next synchronizes (see synchronization discussion following). The 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.
クライアントの状態は、「アクティブである」か「不活発です」。 倉庫は不活発なクライアントをそれらのクライアントと定義します(セットの期間(現在の倉庫実装における1週間)以内に倉庫に接続しません)。 以前に不活発なクライアントが倉庫に接続するとき、倉庫は、それがしばらく不活発であることをクライアントに通知して、それ自体を「リセットするはずです」。 クライアントをリセットすると、あらゆるメッセージをあらゆるメールボックスに置くという影響はクライアントのアップデートリストに与えられます。 これはクライアントを許容します。それであるときに、次に倉庫から新鮮なグローバルなメール状態を得るのは連動します(同期議論が続いているのを見てください)。 リセットは十分なグローバルな州の変化がクライアントが普通の地方の州のグローバルな州の同期を実行するのにあまりに多くの時間を費やすだろう1週間後に起こるという前提に実行されます。
Lambert [Page 5] RFC 1056 PCMAIL June 1988
ランバート[5ページ]RFC1056PCMAIL1988年6月
Messages are stored in mailboxes. Users can have any number of mailboxes, which serve both to store and to categorize messages. 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 mailbox's next available message unique identifier (UID). The above 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)です。 上記の情報は、クライアントがメールボックスの中にすべてのメッセージを読む必要はなくてメールボックスのコンテンツの概要を得るのを許容するためにメールボックスオブジェクトに保存されます。
Some mailboxes are special, in that other users may read the messages stored in them. These mailboxes are called "bulletin board mailboxes" or "bboard mailboxes". The repository uses bboard mailboxes to store bboard mail. Bboard mailboxes differ from ordinary mailboxes in the following ways:
他のユーザがそれらに保存されたメッセージを読むかもしれないので、いくつかのメールボックスが特別です。 これらのメールボックスは「掲示板のメールボックスかbboardメールボックス」と呼ばれます。 倉庫は、bboardメールを保存するのにbboardメールボックスを使用します。 Bboardメールボックスは以下の方法で普通のメールボックスと異なっています:
- Their names are unique across the entire repository;
for instance, only one bboard mailbox named "sf-lovers"
may exist in the entire repository community. This
does not preclude other users from having an ordinary
mailbox named "sf-lovers".
- それらの名前は全体の倉庫の向こう側にユニークです。 例えば、「sf-恋人」という1個のbboardメールボックスだけが全体の倉庫共同体に存在するかもしれません。 これは、「sf-恋人」という普通のメールボックスを持っているので、他のユーザを排除しません。
- Subscribers to the bboard are granted read-only access
to the messages in the bboard mailbox. The bboard
mailbox's owner (typically the system manager) has
read/update/delete access to the mailbox.
- bboardメールボックスの中のメッセージへのbboardへの加入者のリード・オンリー・アクセスは承諾されます。 bboardメールボックスのものは、メールボックスへのアクセスをアップデートするか、または削除します所有者(通常システム・マネージャ)が、/を読んだ。
A bboard subscriber keeps track of the messages he has looked at via a subscription object. The subscription object contains the name of the bboard, its owner (the user who owns the bboard mailbox where all the messages are stored), and the UID of the first message not yet seen by the subscriber.
bboard加入者は彼が購読オブジェクトを通して見たメッセージの動向をおさえます。 購読オブジェクトはbboardの名前、所有者(すべてのメッセージが保存されるbboardメールボックスを所有しているユーザ)、および加入者によってまだ見られていなかった最初のメッセージのUIDを含んでいます。
Users gain read-only access to a bboard by creating a subscription to it; they lose that access when they delete that subscription. A list of all bboard mailboxes available for subscription can be transmitted to the user on demand.
ユーザはそれの購読を作成することによって、bboardへのリード・オンリー・アクセスを獲得します。 その購読を削除するとき、彼らはそのアクセスを失います。 購読に利用可能なすべてのbboardメールボックスのリストをオンデマンドのユーザに伝えることができます。
Associated with each mailbox are any 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 its 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. A descriptor holds the
各メールボックスに関連づけられているのは、いろいろなメッセージオブジェクトです。 2つの部品が各メッセージに細かく分けられます--NIC RFC-822メッセージヘッダーを含むメッセージ・テキスト自体であるメッセージ、および「ボディー」に関する役に立つ情報の概要を含む「記述子。」 所有メールボックスの次の利用可能なUIDに基づく単調に増加するUIDは各メッセージに割り当てられます。 各メールボックスには、それ自身のメールボックス名とユーザ名と共に倉庫の中でメッセージを唯一特定するUIDsのセットがあります。 記述子は成立します。
Lambert [Page 6] RFC 1056 PCMAIL June 1988
ランバート[6ページ]RFC1056PCMAIL1988年6月
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 sixteen flags. These flags are given identifying numbers 0 through 15. Eight of these flags have well-known definitions and are reserved for the repository's use. The eight repository-defined flags mark:
次の情報: メッセージUID、バイト、系列、4つの「役に立つ」メッセージヘッダーフィールド(「日付:」 「以下への」「以下」、および「subject:」 分野)、および16におけるメッセージサイズは弛みます。 No.0〜15を特定しながら、これらの旗を与えます。 これらの8個の旗が、よく知られる定義を持って、倉庫の使用のために予約されます。 8個の倉庫で定義された旗が以下をマークします。
- (#0) whether the message has been deleted
- (#0)、メッセージは削除されました。
- (#1) whether it has been seen
- (#1)、それを見てあります。
- (#2) whether it has been forwarded to the user
- (#2)、それをユーザに送りました。
- (#3) whether it has been forwarded by the user
- (#3)、それはユーザによって進められました。
- (#4) whether it has been filed (written to a text file
outside the repository)
- (#4)、それをファイルしてあります。(倉庫の外のテキストファイルに書かれています)
- (#5) whether it has been printed (locally or remotely)
- (#5)、それは印刷されました。(局所的か離れて)
- (#6) whether it has been replied to
- それがあったか否かに関係なく、(#6)は返答しました。
- (#7) whether it has been copied to another mailbox
- (#7)、別のメールボックスにそれをコピーしてあります。
The remaining eight flags are availble for user use. Descriptors serve as an efficient means for clients to get message information without having to waste time retrieving the entire message from the repository.
残っている8個の旗がユーザ使用のためのavailbleです。 記述子はクライアントが倉庫から全体のメッセージを検索しながら時間を浪費する必要はなくてメッセージ情報を得る効率的な手段として機能します。
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). 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スタイルを倉庫名に翻訳するための手段を倉庫に提供します。 倉庫はそれ自身の名前空間をメッセージ識別に提供します。 三重(ユーザ名、メールボックス名、メッセージ-UID)によってどんなメッセージも唯一特定されます。 どんなメールボックスも組(ユーザ名、メールボックス名)によって唯一特定されます。 メールが扱うRFC822スタイルと倉庫名の間で翻訳するために、倉庫はアドレスオブジェクトのリストを維持します。 それぞれのアドレスオブジェクトはRFC822スタイルアドレスと(ユーザ名、メールボックス名)組との仲間です。 メールがインターネットから到着するとき、倉庫は、(ユーザ名、メールボックス名)組に受取人を翻訳して、正しくメッセージを発送するのにアドレスオブジェクトリストを使用できます。
Lambert [Page 7] RFC 1056 PCMAIL June 1988
ランバート[7ページ]RFC1056PCMAIL1988年6月
4. Communication between repository and client: DMSP
4. 倉庫とクライアントとのコミュニケーション: DMSP
The Distributed Mail System Protocol (DMSP) defines and manipulates the objects mentioned in the previous section. It has been designed to work with Pcmail's singlerepository/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の世界の複数のsinglerepository/クライアントモデルと共に働くように設計されています。 典型的なメールマニピュレーション機能を提供することに加えて、DMSPはグローバルで地方のメール州の簡単な同期を許容する機能を提供します。
DMSP has been completely re-specified in this version of Pcmail. Formerly, DMSP was implemented on top of the USP remote-procedure- call protocol. Since this protocol is not fully unofficially specified (let alone officially specified) anywhere, implementation of USP is difficult for sites wishing to implement Pcmail on different systems. We therefore have decided to completely redesign DMSP. It is now a very simple request/response protocol similar to SMTP or NNTP, running directly on a reliable bidirectional byte- stream such as TCP. The TCP contact port for DMSP has been designated 158. Requests and responses consist of ASCII characters; on octet-based transmission streams, each character is transmitted rightjustified in an octet with the high-order bit cleared to zero.
DMSPはPcmailのこのバージョンで完全に再指定されています。 以前、DMSPはUSPのリモート手順の呼び出ししているプロトコルの上で実装されました。 このプロトコルがどこでも完全に非公式に指定されるというわけではないので(まして、公式に指定されます)、異系統の上でPcmailを実装したがっているサイトに、USPの実装は難しいです。したがって、私たちは、DMSPを完全に再設計すると決めました。 現在それはSMTPかNNTPと同様の非常に簡単な要求/応答プロトコルです、直接TCPなどの信頼できる双方向のバイトの流れで動いて。 DMSPのためのTCP接触ポートは158に指定されました。 要求と応答はASCII文字から成ります。 八重奏ベースのトランスミッションストリームでは、各キャラクタは高位のビットがゼロまできれいにされている状態で八重奏でrightjustifiedされていた状態で伝えられます。
4.1. DMSP commands
4.1. DMSPコマンド
DMSP operations consist of an operation name, followed by zero or
more tab or space characters, followed by zero or more arguments,
each of which is separated from the operation name and other
arguments by one or more space or tab characters. All operation
requests, as well as all responses, must be terminated with a
carriage-return plus line-feed (CR-LF) pair. All operation names and
arguments must be taken from the set of alphanumeric characters plus
the characters dash ("-"), underscore ("_"), and period (".").
DMSP操作はゼロか、より多くの議論があとに続いたそれのそれぞれが1つ以上のスペースかタブキャラクタによって操作名と他の議論と切り離されるゼロがあとに続いた操作名か、より多くのタブか宇宙キャラクタから成ります。 復帰と改行(CR-LF)組と共にすべての操作要求、およびすべての応答を終えなければなりません。 英数字のセット、キャラクタダッシュ(「-」)、強調("_")、および期間からすべての操作名と議論を取らなければならない、(「」、)。
DMSP operation names are case-insensitive; they may be transmitted in any combination of upper and lower case. DMSP arguments are case- insensitive but case-preserving; in other words a mailbox named "MarkL" may be referred to by an operation argument "markl", but will always be stored, and transmitted in a repository response, as "MarkL"; furthermore, any attempt to create a new mailbox "MaRkL" will not be permitted.
DMSP操作名は大文字と小文字を区別しないです。 それらは大文字と小文字のどんな組み合わせでも伝えられるかもしれません。 DMSP議論は、ケース神経が鈍いのですが、ケースを保存しています。 言い換えれば、"MarkL"というメールボックスは操作議論"markl"が示されるかもしれません、倉庫応答でいつも保存されて、伝えられるのを除いて、"MarkL"として。 その上、新しいメールボックス"MaRkL"を作成するどんな試みも受入れられないでしょう。
Each operation argument may contain no more than 64 characters. No single request or response line may contain more than 512 characters, including all white space and the terminating CR-LF.
それぞれの操作議論は64文字未満を含むかもしれません。 どんなただ一つの要求も応答系列もすべての余白と終わっているCR-LFを含む512文字以上を含んではいけません。
4.2. DMSP responses
4.2. DMSP応答
A DMSP operation always results in a response, which may be followed
DMSP操作はいつも応答をもたらします。(それは、続かれるかもしれません)。
Lambert [Page 8] RFC 1056 PCMAIL June 1988
ランバート[8ページ]RFC1056PCMAIL1988年6月
in turn by a list, consisting of zero or more lines of CR-LF-
terminated text terminated by a single period (".") plus a CR-LF. A
response is always prefaced by a three-digit reply code; possible
text following the response code can be in any format. The response
code is sufficient to determine whether the operation succeeded or
failed, or whether more text is forthcoming following the response
line. Any text following the response code is for information only,
and need not follow any particular format.
リストで、順番に、CR-LFの系列がただ一つの期間、aによって終えられたテキストを終えて、ゼロか以上から成った、(「」、)、プラスa CR-LF。 応答は3ケタの回答コードでいつも始められます。 どんな形式にも応答コードに従う可能なテキストがあることができます。 応答コードは、操作が成功したか、失敗した、または応答系列に続いて、より多くのテキストが用意されているかどうか決定するために十分です。 応答コードに従うどんなテキストも、情報だけのためにあって、少しの特定の形式にも続く必要はありません。
The first digit indicates whether the operation succeeded or failed, and if it succeeded whether or not more text should be presented to the repository. Definitions of the first digit are similar to those of NNTP:
最初のケタは操作が成功したか、または失敗して、より多くのテキストが倉庫に提示されるべきであるか否かに関係なく、それが成功したかどうかを示します。 最初のケタの定義はNNTPのものと同様です:
1XX Informative message
1XX Informativeメッセージ
2XX Operation completed successfully
首尾よく完成した2XX Operation
3XX Operation completed successfully, present
remainder of text and terminate with a single
period plus CR-LF pair.
首尾よく完成した3XX Operation、テキストの残りを提示してください、そして、ただ一つの期間とCR-LF組と共に終わってください。
4XX Operation was performed and failed for some
reason.
4XX Operationはある理由で実行されて、失敗されました。
5XX Operation could not be performed because of a
protocol syntax error of some sort.
ある種のプロトコル構文エラーのために5XX Operationを実行できませんでした。
The second digit indicates the type of object referred to by the response.
2番目のケタは応答で言及されたオブジェクトのタイプを示します。
X0X Miscellaneous
X0Xその他
X1X User operation
X1Xユーザ操作
X2X Client operation
X2Xクライアント操作
X3X Mailbox operation
X3Xメールボックス操作
Lambert [Page 9] RFC 1056 PCMAIL June 1988
ランバート[9ページ]RFC1056PCMAIL1988年6月
X4X Subscription operation
X4X購読操作
X5X Message operation
X5Xメッセージ操作
X6X Address operation
X6Xアドレス操作
In an error response, the final digit can describe the type of error that occurred. Otherwise, it simply gives a response a unique number. Numbers 0 through 3 are significant in 4XX-class (error) responses only. Numbers 0-9 in all other responses serve only to differentiate responses dealing with the same type of object under different circumstances.
誤り応答では、最終的なケタは発生した誤りのタイプについて説明できます。 さもなければ、それは単にユニークな数を応答に与えます。 No.0〜3は4XX-クラス(誤り)応答だけで重要です。 他のすべての応答におけるNo.0-9は、単に異なった状況で同じタイプのオブジェクトに対処する応答を差別化するのに役立ちます。
4X0 Operation failed because object exists
4×0 オブジェクトが存在しているので失敗された操作
4X1 Operation failed because object does not exist
4×1 オブジェクトが存在していないので失敗された操作
4X2 Operation failed because of an internal error
4×2 内部エラーで失敗された操作
4X3 Operation failed because of an argument syntax
error
4×3 議論構文エラーで失敗された操作
Each operation generates one of a set of responses, detailed in the protocol specification appendix.
各操作はプロトコル仕様付録で詳しく述べられた1セットの応答の1つを生成します。
List termination is determined solely by a well-known character sequence (CR-LF, period, CR-LF). Since application data could well accidentally contain this termination sequence, the transmitting protocol module must modify application data so it contains no termination sequences. The receiving module must similarly undo the modification before presenting the data to the application at the receiving end.
唯一よく知られるキャラクタシーケンス(以上、CR-LF、CR-LF)でリスト終了は決定します。 アプリケーションデータはたぶん偶然この終止配列を含んでいるでしょう、したがって、伝わっているプロトコルモジュールがアプリケーションデータを変更しなければならないので、それは終止配列を全く含んでいません。 受信モジュールはアプリケーションへのデータを提示する前犠牲者に同様に変更を元に戻さなければなりません。
The transmitting module modifies application data as follows: If a line of application data begins with a period, that period is duplicated. Since the termination sequence is a single period, accidental termination has now been prevented.
伝えるモジュールは以下のアプリケーションデータを変更します: アプリケーションデータの系列が期間で始まるなら、その期間はコピーされます。 終止配列がただ一つの期間であるので、現在、偶然の終了を防いであります。
The receiving protocol checks incoming all incoming data lines for a leading period. A single period is a list terminator; a period followed by other text is removed before being presented to the
受信プロトコルはすべての受信データが主な期間、裏打ちする入来をチェックします。 ただ一つの期間はリストターミネータです。 期間は提示されて、テキストがありながら取り除かれるもう一方で続きました。
Lambert [Page 10] RFC 1056 PCMAIL June 1988
ランバート[10ページ]RFC1056PCMAIL1988年6月
receiving application.
アプリケーションを受け取ります。
4.3. DMSP sessions
4.3. DMSPセッション
A DMSP session proceeds as follows: a client begins the session with the repository by opening a 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セッションは以下の通り続きます: クライアントは、倉庫のマシンに接続を開くことによって、倉庫とのセッションを始めます。 そして、クライアントは「ログイン」操作がある倉庫にそれ自体とそのユーザの両方を認証します。 認証がうまくいくなら、「ログアウトしてください」という操作との接続は倉庫によって閉店させられるセッションを終わらせる前に、ユーザがDMSP操作の特殊活字の数字を実行します。
Because DMSP can manipulate a pair of mail states (local and global) at once, it is extremely important that all DMSP operations are failure-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 consists of a response code possibly followed by information, as described above.
DMSPがすぐに1組のメール州(地方の、そして、グローバルな)を操ることができるので、すべてのDMSP操作が失敗原子であることは、非常に重要です。 どんなDMSP操作の失敗も一貫して、知られている状態の州に両方を残さなければなりません。 この理由で、明白な承認が操作創始者によって受けられない場合、DMSP操作は、失敗したように定義されます。 この承認は情報がことによると上で説明されるようにあとに続いた応答コードから成ります。
Following is a general discussion of all the DMSP operations. The operations are broken down by type: general operations, user operations, client operations, mailbox operations, address operations, subscription operations, and message operations. Detailed operation specifications appear at the end of this document.
以下に、すべてのDMSP操作の一般的な議論があります。 操作はタイプで砕けています: 一般的な操作(ユーザ操作、クライアント操作、メールボックス操作)は操作、購読操作、およびメッセージ操作を扱います。 詳細な操作仕様はこのドキュメントの端に現れます。
4.4. General operations
4.4. 一般操作
The first group of DMSP operations perform general functions that operate on no one particular class of object. DMSP has three general operations which provide the following services:
DMSP操作の最初のグループはオブジェクトのどんな1つの特定のクラスも経営しない一般的な機能を実行します。 DMSPには、以下のサービスを提供する3つの一般的な操作があります:
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. The version number is a natural number like "100", "101", "200". The "send-version" operation should be the first that a client sends to the repository, since no other operation may work correctly if the client and repository are using different versions of DMSP.
DMSPがクライアントと倉庫の間のプロトコルバージョン斜行を防ぐために提供する、「バージョンを発信させる、」 操作 クライアントは議論としてDMSPバージョン番号を供給します。 供給されたバージョン番号が倉庫のDMSPバージョン番号に合っているなら、操作は成功します。 2つのバージョン番号が合っていないなら、それは失敗します。 バージョン番号は「100」、「101」、「200」のように自然数です。 「バージョンを発信させる、」 操作、クライアントが倉庫に送る1番目であるべきです、クライアントと倉庫がDMSPの異なった見解を使用しているなら他の操作が全く正しく働かないかもしれないので。
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 by the message header's destination fields. If one or more of the mailboxes exists outside the repository's user community, the repository is responsible for handing the message to a
を通してユーザが他のユーザにメールを送ることができる、「メッセージを発信させる、」 操作。 メッセージには、NIC RFC-822によって定義されるようにインターネットスタイルヘッダーがなければなりません。 倉庫は、伝言を受け取て、メッセージヘッダーのあて先フィールドによって指定されたメールボックスにそれを分配します。 メールボックスの1つ以上が倉庫のユーザーコミュニティの外に存在しているなら、倉庫はaにメッセージを手渡すのに原因となります。
Lambert [Page 11] RFC 1056 PCMAIL June 1988
ランバート[11ページ]RFC1056PCMAIL1988年6月
local SMTP server. The message envelope is generated by the repository from the message contents since it may be difficult for some clients to perform envelope-generation functions such as address verification and syntax checking.
ローカルのSMTPサーバー何人かのクライアントがアドレス検査や構文の照合などの封筒世代機能を実行するのが、難しいかもしれないので、メッセージ封筒は倉庫によってメッセージ内容から生成されます。
A success acknowledgement is sent from the repository only if (1) the entire message was successfully transmitted from client to repository, and (2) the message header was properly formatted. Once the repository has successfully received the message from the client, any subsequent errors in queueing or delivery must be noted via return mail to the user.
(2) (1) クライアントから倉庫まで首尾よく全体のメッセージを送った場合にだけ、倉庫から成功承認を送りました、そして、適切にメッセージヘッダーをフォーマットしました。 倉庫がクライアントからメッセージをいったん首尾よく受け取ると、ユーザへの返送で待ち行列か配送におけるどんなその後の誤りも述べなければなりません。
The last general operation is the "help" operation. The repository responds to "help" by printing an acknowledgement followed by a list of supported commands, terminated with a period plus CR-LF. The information is intended for display and can be in any format as long as the individual lines of text returned by the repository are CR- LF-terminated.
最後の一般的な操作は「助け」操作です。 倉庫は、期間とCR-LFと共に終えられた支持されたコマンドのリストがあとに続いた承認を印刷することによって「助ける」ために応じます。 倉庫によって返されたテキストの個々の線がCR- LFによって終えられる限り、情報は、表示のために意図して、どんな形式にもあることができます。
4.5. User operations
4.5. ユーザ操作
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 operation takes five arguments: (1) the user's name, (2) the user's password, (3) the name of the client performing the login, (4) a flag set to 1 if the repository should create a client object for the client if one does not exist (0 else), and (5) a flag set to 1 if the client wishes to operate in "batch mode" and 0 if the client wishes to operate in "interactive" mode. The last flag value allows the repository to tune internal parameters for either mode of operation.
DMSP操作の次のシリーズはユーザ物を操作します。 これらの操作で最も変哲もないのは、「ログイン」であり、「ログアウトします」。 ユーザのメール状態にアクセスできる前に、クライアントはログイン操作を実行しなければなりません。 DMSPログイン操作は5つの議論を取ります: (1) (2) (3) ユーザの名前、ユーザのパスワード、クライアントが「対話的な」モードで作動したいならクライアントが「バッチ・モード」と0で作動したいなら、(5) ログインを実行しているクライアントの名前、1つが存在していないなら倉庫がクライアントのためにクライアント物を作成するなら旗が1に設定した(4)(ほかの0)、および旗は1にセットしました。 最後の旗の値は、運転モードのための内部のパラメタを調整するために倉庫を許容します。
The repository can make one of three responses. First, it can make a success response, indicating successful authentication. Second, it can make one of several failure responses, indicating failed authentication. Finally, it can make a special response indicating that authentication was successful, but that the client has not been used in over a week. This last response serves as a hint that the client should consider erasing its local mail state and pulling 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.
倉庫は3つの応答に加わることができます。 まず最初に、それはうまくいっている認証を示して、成功応答をすることができます。 2番目に、失敗した認証を示して、それはいくつかの失敗応答に加わることができます。 最終的に、それは認証がうまくいきましたが、クライアントが1週間以上使用されていないのを示す特別な応答をすることができます。 クライアントが、ローカルのメールを消すと考えるべきであるというヒントが倉庫のメール状態の完全なバージョンの上で述べて、引かれるとき、この最後の応答は役立ちます。 とても多くのメール州の変更が1週間で行われたので通常の同期を実行するのが効率が悪いだろうという前提でこれをします。
When a client has completed a session with the repository, it performs a logout operation. This allows the repository to perform any necessary cleanup before closing the network connection.
ログアウトしてください。クライアントが倉庫とのセッションを終了したとき、aを実行する、操作。 これで、ネットワーク接続を終える前に、倉庫はどんな必要なクリーンアップも実行できます。
Lambert [Page 12] RFC 1056 PCMAIL June 1988
ランバート[12ページ]RFC1056PCMAIL1988年6月
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. Because encryption can be difficult to perform on some resource-poor clients, passwords are transmitted in clear text. Clearly this is not an acceptable long-term solution, and alternatives are welcomed.
ユーザは「セットパスワード」操作で彼のパスワードを変えることができます。 操作はUNIX変化パスワード操作への大体同じことを扱います、議論としてユーザの現在のパスワードと必要な新しいパスワードをみなして。 与えられた現在のパスワードがユーザの現在のパスワードに合っているなら、ユーザの現在のパスワードは与えられた新しいパスワードに変わります。 暗号化は何人かの資源の乏しいクライアントに実行するのが難しい場合があるので、パスワードはクリアテキストで伝えられます。 明確に、これは許容できる長期的な解決法ではありません、そして、代替手段は歓迎されます。
4.6. Client operations
4.6. クライアント操作
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 is a series of lines, one per client, containing the client's name, followed by whitespace, followed by a status string. The status is either "inactive" or "active". As with all text responses, the list is terminated with a period plus CR-LF.
DMSPは、クライアント物を操作するために四則を提供します。 「リストクライアント」という1番目は、ユーザの顧客リストを要求しているクライアントに送るように倉庫に言います。 リストは一連の線です、1クライアントあたり1つ、状態ストリングが支えた空白があとに続いたクライアントの名前を含んでいて。 状態は、「不活発である」か「アクティブです」。 すべてのテキスト応答のように、リストは期間とCR-LFと共に終えられます。
The "create-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 create- client operation is a useful means of creating a number of new client objects while logged into the repository via an existing client. The create-client operation requires as an argument the name of the client to create.
「クライアントを創造する、」 操作、ユーザが彼のクライアント物のリストにクライアント物を追加するのを許容します。 クライアントを創造してください。ログイン操作が「これを作成しているクライアント?」を通してこの機能性をコピーしますが、弛んでください、操作は既存のクライアントを通して倉庫に登録されている間、多くの新しいクライアント物を作成する役に立つ手段です。 クライアントを創造している操作は議論として創造するクライアントの名前を必要とします。
The "delete-client" operation removes an existing client object from a user's client list. The client being removed cannot be in use by anyone at the time. Delete-client also requires as an argument the name of the client to delete.
「クライアントを削除する、」 操作はユーザの顧客リストから既存のクライアント物を取り除きます。 外されているクライアントは当時だれでも使用中であるはずがありません。 クライアントを削除する、また、議論として、クライアントの名前が削除するのが必要です。
The last client operation, "reset-client", causes the repository to place all of the messages in all mailboxes onto the named client's update list. When a client next synchronizes with the repository, it will end up receiving a list of all descriptors when it requests a list of changed message descriptors for a particular mailbox. This is useful for two 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つの理由の役に立ちます。 まず最初に、クライアントの地方のメール状態は容易に無くなるか破損するようになるかもしれません、特にそれがフロッピーディスクに格納されるなら。 2番目に、クライアントが倉庫のそばで不活発であるとしてマークされたなら、リセットクライアント操作は再連動する速い方法に倉庫を提供します、とても多くの違いが地方の、そして、グローバルなメール州の間に存在しているので通常の同期が遠くにあまりに多くの時間がかかると仮定して。
Lambert [Page 13] RFC 1056 PCMAIL June 1988
ランバート[13ページ]RFC1056PCMAIL1988年6月
4.7. Mailbox operations
4.7. メールボックス操作
DMSP supports seven operations that manipulate mailbox objects. First, "list-mailboxes" has the repository send to the requesting client information on each mailbox. The repository transmits one line of information per mailbox, terminating the list with a period plus CR-LF. Each line contains, in order and separated by whitespace, the mailbox name, "next available UID", total message count, and unseen message count. 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はメールボックス物を操作する7つの操作を支持します。 まず最初に、「リストメールボックス」は倉庫をそれぞれのメールボックスの要求しているクライアント情報に発信させます。 期間とCR-LFと共にリストを終えて、倉庫は1メールボックスあたりの情報の1つの台詞を伝えます。 各線は注文であって空白で切り離されるところにメールボックス名、「次の利用可能なUID」、総メッセージカウント、および見えないメッセージカウントを含んでいます。 この操作は地方の、そして、グローバルなメール州を連動させる際に役に立ちます、クライアントがそれでクライアントのローカルのメールボックスリストとユーザのグローバルなメールボックスリストを比べることができるので。 また、コンテンツプレゼントを持っていなくて、メールボックスのリストは各メールボックスのコンテンツの短い概要を提供します。
The "create-mailbox" has the repository create a new mailbox and attach it to the user's list of mailboxes. It takes as an argument the name of the mailbox to create.
「メールボックスを作成する、」、倉庫が新しいメールボックスを作成して、ユーザのメールボックスのリストにそれを付けるのを持っています。 それは議論として作成するメールボックスの名前をみなします。
"Delete-mailbox" removes a mailbox from the user's list of mailboxes. All messages within the mailbox are also deleted and permanently removed from the system. Any address objects binding the mailbox name to RFC-822-style mailbox addresses are also removed from the system. Delete-mailbox takes as an argument the name of the mailbox to delete.
「メールボックスを削除する、」 ユーザのメールボックスのリストからメールボックスを取り外します。 メールボックスの中のすべてのメッセージが、また、削除されて、永久に、システムから取り除かれます。 また、システムからRFC822スタイルメールボックスアドレスにメールボックス名を縛るどんなアドレス物も取り除きます。 メールボックスを削除する、議論として、削除するメールボックスの名前をみなします。
"Create-bboard-mailbox" allows a user to create a bboard mailbox. The name given as an argument must be unique across the entire repository user community. Once the bboard mailbox has been created, other users may subscribe to it, using subscription objects to keep track of which messages they have read on which bboard mailboxes.
「bboardメールボックスを作成してください」で、ユーザはbboardメールボックスを作成できます。 議論として与えられた名前は全体の倉庫ユーザーコミュニティの向こう側にユニークであるに違いありません。 bboardメールボックスがいったん作成されると、他のユーザはそれに加入するかもしれません、動向をおさえるそれらがどのbboardメールボックスの上でそれのメッセージを読んだ購読物を使用して。
"Delete-bboard-mailbox" allows a bboard's owner to delete a bboard mailbox. Subscribers who attempt to read from a bboard mailbox after it has been deleted are told that the bboard no longer exists. Again, the operation's argument is the name of the bboard mailbox to delete.
「bboardメールボックスを削除してください」で、bboardの所有者はbboardメールボックスを削除できます。 それが削除された後にbboardメールボックスから読むのを試みる加入者はbboardがもう存在しないと言われます。 一方、操作の議論は削除するbboardメールボックスの名前です。
"Reset-mailbox" causes the repository to place all of the messages in a named mailbox onto the current client's update list. When the client next requests a list of changed message descriptors for this mailbox, it will receive a list of all message descriptors in the mailbox. 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.
「リセットメールボックス」は倉庫に命名されたメールボックスの中のメッセージのすべてを現在のクライアントのアップデートリストに置かせます。 次のクライアントがこのメールボックスのための変えられたメッセージ記述子のリストを要求するとき、それはメールボックスの中にすべてのメッセージ記述子のリストを受け取るでしょう。 この操作は単にリセットクライアント操作(クライアントは完本のユーザのグローバルなメール状態の上で引くことができる)の、より特定のバージョンです。 第一の使用は偶然局所的にコンテンツを破壊してあるメールボックスのためのものです。
Finally, DMSP has an "expunge-mailbox" operation. Any message can be
最終的に、DMSPが持っている、「メールボックスを梢消する、」 操作。 どんなメッセージもそうであることができます。
Lambert [Page 14] RFC 1056 PCMAIL June 1988
ランバート[14ページ]RFC1056PCMAIL1988年6月
deleted and "undeleted" at will, since this simply changes the value of a flag attached to the message. 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". Expunge-mailbox takes as an argument the name of the mailbox to expunge.
これが単にメッセージに取り付けられた旗の値を変えるので、自由自在に削除して、「非削除しました」。 メールボックスを梢消している操作を実行することによって、削除を永久的にします。 命名されたメールボックスに目を通して、システムからどんなメッセージも取り除くことへの倉庫が「削除されている」とマークした操作原因を梢消してください。 メールボックスを梢消する、議論として、梢消するメールボックスの名前をみなします。
4.8. Address operations
4.8. アドレス操作
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 mailbox. Each address is transmitted on a separate line terminated by a CR-LF; the list is terminated with a period plus CR-LF.
DMSPはユーザがアドレス物を操作できる3つの操作を提供します。 まず最初に、「リストアドレス」操作は特定のメールボックスに関連しているアドレス物のリストを返します。 各アドレスはCR-LFによって終えられた別々の線の上で伝えられます。 リストは期間とCR-LFと共に終えられます。
The "create-address" operation adds a new address object that associates a (user-name, mailbox-name) pair with a given RFC-822- style mailbox address. It takes as arguments the mailbox name and the address name.
「アドレスを作成する、」 操作、RFC-822スタイルの与えられたメールボックスアドレスに(ユーザ名、メールボックス名)組を関連づける新しいアドレス物を加えます。 それは議論としてメールボックス名とアドレス名をみなします。
Finally, the "delete-address" operation destroys the address object binding the given RFC-822-style mail address and the given (user- name, mailbox-name) pair. Arguments are the address to delete and the mailbox it belongs to.
最終的である、「アドレスを削除する、」 操作、与えられたRFC822スタイル郵便の宛先と与えられた(ユーザ名、メールボックス名)組を縛るアドレス物を破壊します。 議論は、削除するアドレスとそれが属すメールボックスです。
4.9. Subscription operations
4.9. 購読操作
DMSP provides five subscription operations. The first, "list- subscriptions", gives the user a list of the bboards he is currently subscribing to. The list consists of one line of information per subscription. Each entry contains the following information, in order:
DMSPは5つの購読操作を提供します。 「リスト購読」という1番目は彼が現在加入しているbboardsのリストをユーザに与えます。 リストは1購読あたりの情報の1つの線から成ります。 各エントリーはオーダーにおける以下の情報を含んでいます:
- The bulletin board's name
- 掲示板の名前
- The UID of the first message the subscriber has not yet
seen
- 加入者がまだ見ていない最初のメッセージのUID
- The number of messages the subscriber has not yet seen
- 加入者がまだ見ていないメッセージの数
- The highest message UID in the bulletin board
- 掲示板の最も高いメッセージUID
"List-available-subscriptions" gives the user a list of all bboards he can subscribe to. The list consists of bboard names, one per line, terminated by a period plus CR-LF. "Createsubscription" adds a subscription to the user's list of subscriptions; it takes as an argument the name of the bboard to subscribe to. "Delete- subscription" removes a subscription from the list, and takes as an
「リストの利用可能な購読」は彼が加入できるすべてのbboardsのリストをユーザに与えます。 リストは1線あたり1つという名前が期間までに終えたbboardとCR-LFから成ります。 "Createsubscription"はユーザの購読のリストの購読を加えます。 それは議論として加入するbboardの名前をみなします。 「購読を削除してください」は、リストから購読を取り除いて、取ります。
Lambert [Page 15] RFC 1056 PCMAIL June 1988
ランバート[15ページ]RFC1056PCMAIL1988年6月
argument the name of the subscription to remove. Note that this does not delete the associated bboard mailbox (obviously only the bboard's owner can do that). It merely removes the user from the list of the bboard's subscribers. Finally DMSP allows the user to tell the repository which messages in a bboard he has seen. Every subscription object contains the UID of the first message the user has not yet seen; the "reset-subscription" operation updates that number, insuring that the user sees a given bboard message only once. Reset-subscription takes as arguments the name of the subscription and the new UID value.
議論、取り除く購読の名前。 これが関連bboardメールボックスを削除しないことに注意してください(明らかにbboardだけの所有者はそれができます)。 それはbboardの加入者のリストからユーザを単に外します。 最終的にDMSPは彼がbboardのどのメッセージを見たかをユーザを倉庫に言わせます。 あらゆる購読物がユーザがまだ見ていない最初のメッセージのUIDを含んでいます。 ユーザが一度だけ与えられたbboardメッセージを見るのを保障して、「リセット購読」操作はその数をアップデートします。 リセット購読は議論として購読の名前と新しいUID値をみなします。
4.10. Message operations
4.10. メッセージ操作
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.
最も多くの一般的に操られたPcmail物がメッセージです。 したがって、DMSPは、効率的な同期、および1セットの操作が標準のメッセージマニピュレーション機能を実行するのを許容するために特別教書操作を提供します。
A user may request a series of descriptors with the "fetch- 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. If the lower bound UID does not exist, the repository starts the series with the first message with UID greater than the lower bound. Similarly, if the upper bound does not exist, the repository ends the series with the last message with UID less than the upper bound. If certain UIDs within the series no longer exist, the repository obviously does not send them. The repository returns the descriptors in a list with the following format:
ユーザは「フェッチ記述子」操作で一連の記述子を要求するかもしれません。 シリーズはリストの1組のメッセージUIDs、下側を表して、および上限によって特定されます。 UIDsが数を単調に増加させているように定義されるので、1組のUIDsは記述子のシリーズを完全に特定するために十分です。 下界UIDが存在していないなら、UIDが下界よりすばらしい状態で倉庫は最初のメッセージとのシリーズを始めます。 同様に、上限が存在していないなら、倉庫はUIDと共に上限より最後のメッセージとのシリーズを終わらせません。 シリーズの中のあるUIDsがもう存在していないなら、倉庫は明らかにそれらを送りません。 倉庫は以下の形式があるリストの記述子を返します:
If a descriptor has been expunged, the repository transmits two consecutive lines of information: the word "expunged" on one line, followed by the message UID on the next line. "Expunged" notifications are only transmitted in response to a "fetch-changed- descriptors" command; they are an indication to the client that someone else has expunged the mailbox and that the client should remove the local copy of the expunged message.
記述子が梢消されたなら、倉庫は情報の2つの連続した台詞を伝えます: 次の線の上のメッセージUIDによって従われた1つの線で「梢消された」単語。 「梢消された」通知は「フェッチで変えられた記述子」のコマンドに対応して伝えられるだけです。 それらはクライアントへの他の誰かがメールボックスを梢消して、クライアントが梢消されたメッセージの地方のコピーを取り外すべきであるという指示です。
If a descriptor has not been expunged, it is presented as six
consecutive lines of information: the word "descriptor" on the first
line, followed by a second line containing the message UID, flag
states (see examples following), message length in bytes, and message
length in lines, followed by four lines containing in order the
message "from:" field, "to:" field, "date:" field, and "subject:"
field. The entire list of descriptors is terminated by a period plus
CR-LF; individual descriptors are not specially terminated since the
first line ("expunged" or "descriptor") of a list entry determines
記述子が梢消されていないなら、それは情報の6つの連続した線として提示されます: オーダーにメッセージを含んでいて、「記述子」という最初の線に関するメッセージUID、旗国(例が従っているのを見る)、バイトで表現されるメッセージ長、および並んでいるメッセージ長を含むセカンドラインが支えた言葉は4つの線のそばで「以下から」従いました。 「以下への」分野 分野、「以下とデートしてください」 分野、「subject:」 さばきます。 記述子の全体のリストは期間とCR-LFによって終えられます。 特に、リストエントリーの(「梢消」か「記述子」)が決定する最初の線以来個々の記述子は終えられません。
Lambert [Page 16] RFC 1056 PCMAIL June 1988
ランバート[16ページ]RFC1056PCMAIL1988年6月
the exact length of the entry (two lines or six lines).
エントリー(2つの線か6つの線)の正確な長さ。
The "fetch-changed-descriptors" operation is intended for use during state synchronization. Whenever a descriptor changes state (one of its flags is cleared, for example), the repository notes those clients which have not yet recorded the change locally. Fetch- changed-descriptors has the repository send to the client a maximum of the first N descriptors which have changed since the client's last synchronization, where N is a number sent by the client. The list sent begins with the descriptor with lowest UID. Note that the list of descriptors is only guaranteed to be monotonically increasing for a given call to "fetch-changed-descriptors"; messages with lower UIDs may be changed by other clients in between calls to "fetch- changeddescriptors". "Fetch-changed-descriptors" takes two arguments: the name of the mailbox to search, and the maximum number of descriptors for the repository to return.
「変えられた記述子をとって来てください」という操作は使用のために州の同期の間、意図します。 記述子が状態を変える(例えば、旗の1つは儲けられます)ときはいつも、倉庫はそれらのクライアントに注意します(まだ局所的に変化を記録していません)。 倉庫はフェッチの変えられた記述子で最大クライアントの最後の同期以来変化している最初Nの記述子をクライアントに送ります、Nがクライアントによって送られた数であるところで。 送られたリストは最も低いUIDと共に記述子で始まります。 記述子のリストが与えられた呼び出しのために「フェッチは記述子を変えたこと」に単調に増加しているように保証されるだけであることに注意してください。 下側のUIDsがあるメッセージは「changeddescriptorsをとって来る」という要求の間で他のクライアントによって変えられるかもしれません。 「フェッチは記述子を変えたこと」は2つの議論を取ります: 捜すメールボックスの名前、および倉庫が返す記述子の最大数。
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-descriptors" command causes the repository to mark as "recorded by current client" a given series of descriptors. The series is identified by a low UID and a high UID. UIDs within the series that no longer exist are ignored. Arguments are: mailbox name, low UID in range, and high UID in range.
変えられた記述子がいったん見られると、ユーザは、現在のクライアントが局所的に変化を記録したことを倉庫に知らせたくなるでしょう。 「リセット記述子」コマンドは、与えられたシリーズに関する記述子を「現在のクライアントで、記録する」ので、マークへの倉庫を引き起こします。 シリーズは低いUIDと高いUIDによって特定されます。 もう存在しないシリーズの中のUIDsは無視されます。 議論は以下の通りです。 メールボックス名、範囲の低いUID、および範囲の高いUID。
Whole messages are transmitted from repository to user with the "fetch-message" operation. The separation of "fetchdescriptors" and "fetch-message" operations allows clients with small amounts of disk storage to obtain a small message summary (via "fetch-descriptors" or "fetch-changed-descriptors") without having to pull over the entire message. Arguments are mailbox name, followed by message UID.
全体のメッセージは「フェッチメッセージ」操作で倉庫からユーザまで送られます。 "fetchdescriptors"と「フェッチメッセージ」操作の分離で、全体のメッセージの上で引く必要はなくて、少量のディスク格納のクライアントは小さいメッセージ概要(「フェッチ記述子」か「フェッチは記述子を変えたこと」を通した)を得ることができます。 議論はメッセージUIDによっていうことになられたメールボックス名です。
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. Arguments are: mailbox name, followed by message UID, followed by printer identification.
頻繁に、メッセージは何人かのクライアントが局所的に格納できないくらい大きいかもしれません。 ユーザは「印刷メッセージ」操作でまだメッセージ内容を見ることができます。 この操作で、倉庫はメッセージのコピーを命名されたプリンタに送ります。 プリンタ名は特定の倉庫実現に意味を持つだけでよいです。 DMSPは単に識別の手段として名前を伝えます。 議論は以下の通りです。 プリンタ識別でメッセージUIDによって従われたメールボックス名は従いました。
Copying of one message into another mailbox is accomplished via the "copy-message" operation. A descriptor list of length one, containing a descriptor for the copied message, is returned if the copy operation is successful. This descriptor is required because the copied message acquires a UID different from the original message. The client cannot be expected to know which UID has been assigned the copy, hence the repository's sending a descriptor
別のメールボックスの中に1つのメッセージをコピーするのは「コピーメッセージ」操作で実行されます。 コピーされたメッセージのための記述子を含んでいて、コピー操作がうまくいくなら、長さ1の記述子リストを返します。 コピーされたメッセージがオリジナルのメッセージと異なったUIDを獲得するので、この記述子が必要です。 クライアントが、したがって、コピー、倉庫が記述子を送るのをどのUIDに割り当ててあるかを知っていることを期待できません。
Lambert [Page 17] RFC 1056 PCMAIL June 1988
ランバート[17ページ]RFC1056PCMAIL1988年6月
containing the UID. Arguments to copy-message are: source mailbox name, target mailbox name, and source message UID.
UIDを含んでいます。 コピーメッセージへの議論は以下の通りです。 ソースメールボックス名、目標メールボックス名、およびソースメッセージUID。
Each message has associated with it sixteen flags, as described earlier. These flags can be set and cleared using the "set-message- flag" operation. The first eight flags have special meaning to the repository as described above; the remaining eight are for user use. Set-message-flag takes four arguments: mailbox name, message UID, flag number (0 through 15), and desired flag state (0 or 1).
各メッセージは、より早く説明されるように16個の旗をそれに関連づけました。 「メッセージを設定している旗」の操作を使用することでこれらの旗を設定して、きれいにすることができます。 最初の8個の旗が上で説明されるように特別な意味を倉庫に持っています。 残っている8はユーザ使用のためのものです。 セットメッセージ旗は4つの議論を取ります: メールボックス名、メッセージUIDは数(0〜15)、および必要な旗国(0か1)に旗を揚げさせます。
5. Client Architecture
5. クライアント構造
Clients can be any of a number of different workstations; Pcmail's architecture must therefore take into account the range of characteristics of these workstations. First, most workstations are much more affordable than the large computers currently used for mail service. It is therefore possible that a user may well have more than one. Second, some workstations are portable and they are not expected to be constantly tied into a network. Finally, many of the smaller workstations 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 different characteristics.
クライアントは異なったワークステーションの数のいずれであることができますも。 したがって、Pcmailの構造はこれらのワークステーションの特性の範囲を考慮に入れなければなりません。 まず最初に、ほとんどのワークステーションが現在メールサービスに使用されている大きいコンピュータよりはるかに手頃です。 したがって、ユーザには1つ以上がたぶんあるだろうというのは、可能です。 2番目に、いくつかのワークステーションが携帯用です、そして、絶えずネットワークに結ばれないと予想されます。 したがって、資源の乏しくて、より小さいワークステーションでは、それらはそうです。最終的に多く、局所的にかなりの量の州の情報を格納できると予想しませんでした。 以下の小区分はこれらの異なった特性を記述するPcmailのクライアント構造の特定の部分について説明します。
5.1. Multiple clients
5.1. 複数のクライアント
The fact that Pcmail users may own more than one workstation forms the rationale for the multiple client model that Pcmail uses. A Pcmail user may have one client at home, another at an office, and maybe even a third portable client. 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 places no restrictions on a user's ability to communicate with the repository from several clients at the same time. Instead, the decision to allow several clients concurrent access to a user's mail state is made by the repository implementation.
Pcmailユーザが1台以上のワークステーションを所有するかもしれないという事実はPcmailが使用する複数のクライアントモデルのために原理を形成します。 Pcmailユーザは家の1人のクライアント、オフィスの別のもの、および多分3番目の携帯用のクライアントさえ飼うかもしれません。 各クライアントはユーザのメール状態、したがって、別々のコピーのPcmailの分配された本質を維持します。 別々のクライアントの概念で、Pcmailユーザはいくつかの別の場所からメール状態にアクセスできます。 Pcmailは同時に倉庫で数人のクライアントから交信するユーザの能力に関して制限を全く課しません。 代わりに、倉庫実現でユーザのメール状態への同時発生のアクセスを数人のクライアントに許すという決定をします。
5.2. Synchronization
5.2. 同期
Some workstations tend to be small and fairly portable; the likelihood of their always being 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
いくつかのワークステーションが、小さくて、かなり携帯用である傾向があります。 それらがいつもネットワークに関連しているという見込みは比較的小さいです。 これは各クライアントが地方のコピーのユーザのメール状態を維持する別の理由です。 そして、ユーザはネットワーク(そして、倉庫)に関連づけられていない間、地方のメール状態を操ることができます。 これはすぐに、地方の、そして、グローバルなメール州の間に同期の問題を持って来ます。 倉庫はaに絶えずどちらかフォームでグローバルなメール州の最新版を受けるのを置くことです。
Lambert [Page 18] RFC 1056 PCMAIL June 1988
ランバート[18ページ]RFC1056PCMAIL1988年6月
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.
入って来るメール、他のクライアントからの変化の形 いつもネットに接続されるというわけではないクライアントはすぐに、グローバルな変化を受けることができません。 さらに、クライアントのユーザは地方のメール状態で彼自身の変更を行うことができます。
Pcmail's architecture allows fast 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 three ways: first, one of its sixteen flag values can be changed (this encompasses the user's reading an unseen message, deleting a message, printing a message, etc). Second, a descriptor can be created, either by the delivery of a new message or by the copying of a message from one mailbox to another. Finally, a descriptor can be destroyed, via an "expunge-mailbox" operation.
3つの方法の1つで既存の記述子を変えることができます: まず最初に、16の旗の値の1つを変えることができます(これは、ユーザが見えないメッセージを読むのを取り囲みます、メッセージを削除して、メッセージなどを印刷して)。 2番目に、新しいメッセージの配送かメッセージの1個のメールボックスから別のメールボックスまでのコピーで記述子を作成できます。 を通して最終的に、記述子を無効にすることができる、「メールボックスを梢消する、」 操作。
In the above cases, synchronization is required between the repository and every client that has not previously noted the change. To keep track of which clients have noticed a global mail state change and changed their local states accordingly, each mailbox has associated with it a list of active clients. Each client has a (potentially empty) "update list" of messages which have changed since that client last synchronized.
上の場合では、同期が変化について上述していない倉庫とすべてのクライアントの間で必要です。 どのクライアントがグローバルなメール状態が変化するのに気付いて、変化したかに関する道が地元の州であることを保つために、それに従って、各メールボックスは活発なクライアントのリストをそれに関連づけました。 各クライアントには、そのクライアントが最後に連動して以来変化しているメッセージの(潜在的に空)の「アップデートリスト」があります。
When a client connects to the repository, it executes a DMSP "fetch- changed-descriptors" operation. This causes the repository to return a list of all descriptors on that client's update list. When the client receives the changed descriptors, it may do one of two things: if the descriptor is marked "expunged", it can remove the corresponding message from the local mailbox. If the descriptor is not expunged, the client can store the descriptor, thus updating the local mail state. After a changed descriptor has been recorded, the client uses the DMSP "reset-descriptors" operation to remove descriptors from its update list. Those descriptors will now not be sent to the client unless (1) it is explicitly requested via a "fetch-descriptors" operation, or (2) it changes again.
クライアントが倉庫に接続するとき、それはDMSP「フェッチの変えられた記述子」操作を実行します。 これで、倉庫はそのクライアントのアップデートリストですべての記述子のリストを返します。 クライアントが変えられた記述子を受け取るとき、2つのものの1つをするかもしれません: 記述子が「梢消されている」とマークされるなら、それは地方のメールボックスから対応するメッセージを取り除くことができます。 記述子が梢消されないなら、クライアントは記述子を格納して、その結果、地方のメール状態をアップデートできます。 変えられた記述子が記録された後に、クライアントは、アップデートリストから記述子を取り除くのにDMSP「リセット記述子」操作を使用します。 (2) (1) それが「フェッチ記述子」操作で明らかに要求されない場合、それらの記述子が現在、クライアントに送られないだろうか、またはそれは再び変化します。
Lambert [Page 19] RFC 1056 PCMAIL June 1988
ランバート[19ページ]RFC1056PCMAIL1988年6月
In this manner, a client can run through its user's mailboxes, getting all changes, incorporating them into the local mail state, and marking the changes as recorded.
この様に、クライアントはユーザのメールボックスを貫くことができます、すべての変化を得て、地方のメール状態にそれらを組み入れて、記録されるとして変化をマークして。
5.3. Batch operation versus interactive operation
5.3. バッチ運転対対話的な操作
Because of the portable nature of some workstations, they may not always be connected to a network (and able to communicate with 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 also immediately made to the global state via DMSP operations.
いくつかのワークステーションの携帯用の自然のために、それらは、いつもネットワークに関連するのと(倉庫で交信できます。)であるかもしれないというわけではありません。 各クライアントが地方のメール状態を維持するので、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; this incorporates 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; although one synchronization is required when the client first opens a connection to the repository, subsequent synchronizations can be performed either at the user's request or automatically every so often by the client.
会話型では、地域変化がすぐに倉庫に伝播されるので、バッチ型操作の最初の部分は排除されます。 また、同期の過程は変化します。 クライアントが最初に倉庫に接続を開くと、1つの同期が必要ですが、クライアントは時々、ユーザの要求か自動的のどちらかにその後の連動を実行できます。
5.4. Message summaries
5.4. メッセージ概要
Smaller workstations may have little in the way of disk storage. Clients running on these workstations 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.
より小さいワークステーションは少ししかディスク格納の方法で持っていないかもしれません。 これらのワークステーションで動いているクライアントは完全な地方のコピーのユーザのグローバルなメール状態に十分な余地を決して持っていないかもしれません。 これは、ユーザのものが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 (contained in the eight system-defined and eight user-defined flags), and portions of its
大容量ストレージを取らないで、記述子はメッセージ情報を提供します。 各記述子はメッセージの情報の概要を含んでいます。 この情報がメッセージUID、バイトと線における長さ、状態(8では、システムで定義されるのと8個のユーザによって定義された旗を含んでいる)、および部分を含んでいる、それ
Lambert [Page 20] RFC 1056 PCMAIL June 1988
ランバート[20ページ]RFC1056PCMAIL1988年6月
RFC-822 header (the "from:", "to:", "date:" and "subject:" 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ヘッダー、(「以下のこと」という「以下」が「以下の日付を入れる」、「subject:」 分野、) 長さがそれが説明するメッセージのサイズから独立している(およそ100バイト)の小さいデータ構造でこの情報のすべてをコード化できます。
Most clients 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. If a client has extremely limited amounts of disk storage, it is also possible to get a subset of the descriptors from the repository. 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 operation.
ほとんどのクライアントは問題でほとんどメッセージ記述子に関する全リストを格納できないべきです。 これで、ユーザは彼のすべてのメッセージを持っていることのない彼のメール状態の完全な絵を局所的に存在させることができます。 また、クライアントに非常に限られた量のディスク格納があるなら、倉庫から記述子の部分集合を得るのも可能です。 短いメッセージが記述子に伴うクライアントの上にあることができて、特に、長いメッセージをDMSP印刷メッセージ操作で印刷するか、またはフェッチメッセージ操作で引くことができます。
6. Typical interactive-style client-repository interaction
6. 典型的な対話的なスタイルクライアント倉庫相互作用
The following example describes a typical communication session between the repository and a client mail reader. The client is one of three belonging to user "Fred". Its name is "office-client", and since Fred has used the client within the last week, it is marked as "active". Fred has two mailboxes: "fred" 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. Typically, the synchronization will be performed by a mail reader as part of a "get new mail" operation.
以下の例は倉庫とクライアントメール読者との典型的なコミュニケーションセッションについて説明します。 クライアントはユーザ「フレッド」に属す3の1つです。 名前は「オフィスクライアント」です、そして、フレッドが最後の週中にクライアントを使用して以来、それは「アクティブである」としてマークされます。 フレッドは2個のメールボックスを持っています: "fred"は彼の現在のメールのすべてが格納されるところです。 「アーカイブ」は永久に重要なメッセージが保たれるところです。 例は簡単な同期操作を貫くでしょう。 通常、同期は「新しいメールを得てください」という操作の一部としてメール読者によって実行されるでしょう。
First Fred's mail reader connects to the repository and receives the following banner:
まず最初に、フレッドのメール読者は、倉庫に接続して、以下のバナーを受け取ります:
200 Pcmail repository version 3.0.0 ready
200Pcmail倉庫バージョン3.0.0準備ができています。
In order to access his global mail state, the mail reader must authenticate Fred to the repository; this is done via the DMSP login operation:
彼のグローバルなメール状態にアクセスするために、メール読者は倉庫にフレッドを認証しなければなりません。 DMSPログイン操作でこれをします:
login fred fred-password office-client 0 0
ログインfred fred-パスワードオフィスクライアント0 0
This tells the repository that Fred is logging in via "office- client", and that "office-client" is identified by an existing client object in Fred's mail state. The first argument to the login operation is Fred's repository user name. The second argument is Fred's password. The third argument is the name of the client communicating with the repository. The fourth argument tells the repository not to create "office-client" even if it cannot find its client object. The final argument tells the repository that Fred's client is not operating in batch mode but rather in interactive mode.
これは、フレッドが「オフィスクライアント」を通してログインしていると倉庫に言います、そして、その「オフィスクライアント」はフレッドのメール状態で既存のクライアント物によって特定されます。 ログイン操作への最初の議論はフレッドの倉庫ユーザ名です。 2番目の議論はフレッドのパスワードです。 3番目の議論は倉庫で交信するクライアントの名前です。 4番目の議論は、クライアント物を見つけることができないでも「オフィスクライアント」を作成しないように倉庫に言います。 最終弁論は、フレッドのクライアントがバッチ・モード、しかし、むしろ会話型で働いていないと倉庫に言います。
Lambert [Page 21] RFC 1056 PCMAIL June 1988
ランバート[21ページ]RFC1056PCMAIL1988年6月
Fred's authentication checks out, so the repository logs him in.
フレッドの認証がチェックアウトされるので、倉庫は彼にログインします。
200 command OK
200コマンドOK
Now that Fred is logged in, the mail reader performs an initial synchronization. This process starts with the mail reader's asking for an up-to-date list of mailboxes:
フレッドがログインされるので、メール読者は初並列を実行します。 この過程は、メール読者がメールボックスの最新のリストを求めると始まります:
list-mailboxes
リストメールボックス
The repository replies with:
以下がある倉庫回答
230 mailbox list follows:
fred 2313 10 1
archive 101 100 0
.
230メールボックスリストは従います: fred2313 10 1アーカイブ101 100 0。
This tells the mail reader that there are two mailboxes, "fred" and "archive". "Fred" has 10 messages, one of which is unseen. The next incoming message will be assigned a UID of 2313. "Archive", on the other hand, has 100 messages, 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 mail reader would create them. On the other hand, if some mailboxes in the mail reader'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個のメールボックス、"fred"、および「アーカイブ」があるとメール読者に言います。 「フレッド」には、10のメッセージがあります。その1つは見えないです。 2313年のUIDは次の入力メッセージに割り当てられるでしょう。 他方では、「アーカイブ」には、100のメッセージがあります。そのいずれも見えなくはありません。 UID101は「アーカイブ」に送られた次のメッセージに割り当てられるでしょう。 リストにはどんな新しいメールボックスもありません。(あれば、メール読者はそれらを作成するでしょうに。 他方では、メール読者のローカルのリストのいくつかのメールボックスが倉庫のリストにないなら、プログラムは、別のクライアントによって削除されて、それらを仮定して、局所的にまた、それらを削除するでしょうに。).
To synchronize, the mail reader 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 mail reader asks for any changed descriptors via the "fetch- changed-descriptors" operation. It requests at most ten changed descriptors since storage is very limited on Fred's workstation.
メール読者は「フェッチの変えられた記述子」操作でどんな変えられた記述子も求めます。 それは、格納がフレッドのワークステーションの上で非常に限られているので10が記述子を変えたよう高々要求します。
fetch-changed-descriptors fred 10
フェッチが記述子を変えているfred10
The repository responds with:
倉庫は以下で応じます。
250 descriptor list follows:
expunged
250記述子リストは従います: 梢消されます。
Lambert [Page 22] RFC 1056 PCMAIL June 1988
ランバート[22ページ]RFC1056PCMAIL1988年6月
2101
expunged
2104
descriptor
2107 1100011100000010 1400 30
foo@bar.edu (Foo Jones)
fred@PTT.LCS.MIT.EDU
Wed, 9 Dec 87 10:43:52 EST
A typical subject line
descriptor
2312 0000000000000000 12232 320
joe@athena.mit.edu
fred@PTT.LCS.MIT.EDU
Thu, 17 Dec 87 18:24:09 PST
Another typical subject line
.
2101は水曜日に2104年の記述子2107 1100011100000010 1400 30 foo@bar.edu (Fooジョーンズ) fred@PTT.LCS.MIT.EDU を梢消しました、1987年12月9日のA典型的な件名記述子2312 0000000000000000 12232 320 joe@athena.mit.edu fred@PTT.LCS.MIT.EDU木曜日の東部標準時10時43分52秒、1987年12月17日の太平洋標準時18時24分9秒のAnotherの典型的な件名。
If a descriptor changed because it was expunged, it is transmitted as two lines: the word "expunged" on one line, followed by the message UID on the next line. If one of its flags changed state, or it is a new message, it is transmitted as six lines: the word "descriptor" on one line, followed by a line containing the message UID, flags, and length in bytes and lines, followed by the to, from, date, and subject fields, each on one line. The flags are transmitted as a single string of ones and zeroes, a one if the flag is on and a zero if the flag is off. All 16 flags are always transmitted. Flag zero's state is the first character in the flag string; flag fifteen's is the last character in the flag string.
それが梢消されたので記述子が変化したなら、それは2つの系列として伝えられます: 次の系列のメッセージUIDによって続かれた1つの系列で「梢消された」単語。 旗の1つが状態を変えたか、新しいメッセージであるなら、それは6つの系列として伝えられます: 「記述子」というバイトと系列におけるUID、旗、および長さが従ったメッセージを含む系列があとに続いた1つの系列に関する言葉、期日、および対象の分野(1つの系列のそれぞれ) 旗は旗がオフであるなら、旗がオンであって、ゼロであるならものとゼロ、1つの一連として送られます。 すべての16個の旗がいつも送られます。 旗は旗のストリングでゼロのものが、述べる最初のキャラクタです。 旗のものfifteenは旗のストリングで最後のキャラクタです。
The first two descriptors in the list have been expunged, presumably by Fred's expunging his mailbox on another client. The mail reader removes messages 2101 and 2104 from its local copy of mailbox "fred". The next descriptor in the list is one which Fred marked for deletion on another client yesterday. The mail reader marks the local version of the message as deleted. The last descriptor in the list is a new one. The mail reader adds the descriptor to its local list. Since all changes to mailbox "fred" have now been recorded locally, the update list can be reset:
おそらく、フレッドが別のクライアントで彼のメールボックスを梢消することによって、リストの最初の2つの記述子が梢消されました。 メール読者は地方のコピーのメールボックスからの"fred"というメッセージ2101と2104を取り除きます。 リストの次の記述子は昨日の別のクライアントの上のフレッドが削除のためにマークしたものです。 メール読者は削除されるようにメッセージのローカルのバージョンをマークします。 リストにおける最後の記述子は新しいものです。 メール読者はローカルのリストに記述子を追加します。 メールボックス"fred"へのすべての変化が現在局所的に記録されて以来、アップデートリストをリセットできます:
reset-descriptors fred 1 2312
リセット記述子fred1 2312
The repository responds with:
倉庫は以下で応じます。
200 command OK
200コマンドOK
indicating that it has removed from "office-client"'s update list all
それが「オフィスクライアント」から取り外してあるのを示すのによるアップデートがすべてを記載するということです。
Lambert [Page 23] RFC 1056 PCMAIL June 1988
ランバート[23ページ]RFC1056PCMAIL1988年6月
messages in mailbox "fred" with UIDs between 1 and 2312 inclusive (in this case just two messages). "Fred" has now been synchronized. The mail reader now turns to Fred's "archive" mailbox and asks for the first ten changed descriptors.
UIDs1〜2312が包括的のメールボックス"fred"(この場合ちょうど2つのメッセージ)のメッセージ。 「フレッド」は現在、連動しました。 メール読者は、今、フレッドの「アーカイブ」メールボックスに変わって、最初の10の変えられた記述子を求めます。
fetch-changed-descriptors archive 10
フェッチが記述子を変えているアーカイブ10
The repository responds with:
倉庫は以下で応じます。
250 descriptor list follows:
.
250記述子リストは従います: .
The zero-length list tells the mail reader that no descriptors have been changed in "archive" since its last synchronization. No new synchronization needs to be performed.
ゼロ・レングスリストは、最後の同期以来記述子が全く「アーカイブ」で変えられていないとメール読者に言います。 どんな新しい同期も、実行される必要がありません。
Fred's mail reader is now ready to pull over the new message. The message is 320 lines long; there might not be sufficient storage on "office-client" to hold the new message. The mail reader tries anyway:
フレッドのメール読者は現在、新しいメッセージの上で引く準備ができています。 長い間、メッセージは320の系列です。 十分なストレージが新しいメッセージを保持する「オフィスクライアント」にないかもしれません。 メール読者はとにかく試みます:
fetch-message fred 2312
フェッチメッセージfred2312
The repository begins transmitting the message:
倉庫はメッセージを送り始めます:
251 message follows:
UID: 2312
From: joe@bar.mit.edu
To: fred@PTT.LCS.MIT.EDU
Date: Thu, 17 Dec 87 18:24:09 PST
Subject: Another typical subject line
251メッセージは従います: UID: 2312 From: joe@bar.mit.edu To: fred@PTT.LCS.MIT.EDU 日付: 木曜日、1987年12月17日の太平洋標準時18時24分9秒Subject: 別の典型的な件名
Fred,
フレッド
...
...
Halfway through the message transmission, Fred's workstation runs out of disk space. Because all DMSP operations are defined to be failure-atomic, the portion of the message already transmitted is destroyed locally and the operation fails. The mail reader informs Fred that the message cannot be pulled over because of a lack of disk space. The synchronization process is now finished and Fred can start reading his mail. The new message that was too big to fit on "office-client" will be marked "off line"; Fred can use the mail
途中で、メッセージ送信で、フレッドのワークステーションは椎間腔を使い果たします。 すべてのDMSP操作が失敗原子であるために定義されるので、既に送られたメッセージの部分は局所的に破壊されます、そして、操作は失敗します。 メール読者は、椎間腔の不足のためにメッセージを引くことができないことをフレッドに知らせます。 同期プロセスは今終わっています、そして、フレッドは彼のメールを読み始めることができます。 「オフィスクライアント」で合うことができないくらい大きかった新しいメッセージは「オフライン」であるとマークされるでしょう。 フレッドはメールを使用できます。
Lambert [Page 24] RFC 1056 PCMAIL June 1988
ランバート[24ページ]RFC1056PCMAIL1988年6月
reader to either remote-print it or delete and expunge other messages until he has enough space to store the new message.
または、リモート・プリントへの読者、それ、彼には新しいメッセージを保存できるくらいのスペースがあるまで、他のメッセージを削除して、梢消してください。
Since Fred is running in interactive mode, changes he makes to any messages will immediately be transmitted into DMSP operations and sent to the repository. Depending on the mail reader implementation, Fred will either have to execute a "synchronize" command periodically or the client will synchronize for him automatically every so often.
フレッドが会話型へ駆け込んでいるので、すぐに、彼がどんなメッセージにもする変更をDMSP操作に伝えて、倉庫に送るでしょう。 メール読者実装によって、フレッドが定期的に「連動」コマンドを実行しなければならない、さもなければ、クライアントは時々、彼のために自動的に連動するでしょう。
7. A current Pcmail implementation
7. 現在のPcmail実装
The following section briefly describes a current Pcmail system that services a small community of users. The Pcmail repository runs under UNIX on a DEC Microvax-II connected to the Internet. The clients run on IBM PCs, XTs, and ATs, as well as Sun workstations, Microvaxes, and VAX-750s.
以下のセクションは簡潔にユーザの小規模地域社会にサービスを提供する現在のPcmailシステムについて説明します。 Pcmail倉庫はインターネットに関連づけられた12月のMicrovax-IIでUNIXで実行されます。 クライアントはIBM PC、XTs、ATs、Sunワークステーション、Microvaxes、およびVAX-750の上で作業します。
7.1. IBM PC client code
7.1. IBM PCクライアントコード
Client code for the IBM machines operates only in batch mode. Users make local state changes in a mail reader; the changes are queued until the user runs a network client program. The program connects to the repository, performs the queued changes, and synchronizes local and global mail states. The network client program then disconnects from the repository.
IBMマシンのためのクライアントコードは単にバッチ・モードで作動します。 ユーザはメール読者の地方の州の変更を行います。 ユーザがネットワーククライアントプログラムを動かすまで、変化は列に並ばせられます。 プログラムは、倉庫に接続して、列に並ばせられた変化を実行して、地方の、そして、グローバルなメール州を連動させます。 そして、ネットワーククライアントプログラムは倉庫から切断します。
The IBM PC client code has gone through several revisions since the first Pcmail RFC was published. What was once a fairly primitive and cumbersome system has evolved into a system that makes excellent use of the PC's limited resources and provides a fairly powerful, easy- to-use mail reader.
最初のPcmail RFCが発行されて以来、IBM PCクライアントコードはいくつかの改正に直面しています。 一度aはことでした。公正に、原始的で扱いにくいシステムはPCの限りある資源の素晴らしい使用をして、使用へのかなり強力で、簡単なメール読者を提供するシステムに発展しました。
Users access and modify their local mail state via a mail reader written in the Epsilon text editor's EEL extension language. Users are given a variety of commands to operate on individual messages and mailboxes, as well as to compose outgoing mail.
ユーザは、EpsilonテキストエディタのEEL拡大言語で書かれているメール読者を通して地元のメール状態にアクセスして、変更します。 個々のメッセージとメールボックスを作動させて、送信するメールを構成するさまざまなコマンドをユーザに与えます。
Synchronization and the processing of queued changes is performed by a separate program, which the user runs as desired. The program takes any actions queued while operating the mail reader, and converts them into DMSP operations. All queued changes are made before any synchronization is performed. The program can be invoked directly from the mail reader, without having to exit and restart.
列に並ばせられた変化の同期と処理は別々のプログラムで実行されます。(ユーザは望まれているようにそれを動かします)。 プログラムは、メール読者を手術している間に列に並ばせられたどんな行動も取って、DMSP操作にそれらを変換します。 どんな同期も実行される前にすべての列に並ばせられた変更が行われます。 出て、再開する必要はなくて、直接メール読者からプログラムを呼び出すことができます。
The limitation of IBM PC client operation to batch mode was made because of development environment limitations. The mail reader cannot work with the network code inside it because of the network program architecture. The only solution was to provide a two-part
開発環境制限のためにバッチ・モードへのIBMのPCクライアント操作の制限をしました。 メール読者は全国番組アーキテクチャのためにそれの中でネットワークコードで働くことができません。 唯一のソリューションは2部分を提供することでした。
Lambert [Page 25] RFC 1056 PCMAIL June 1988
ランバート[25ページ]RFC1056PCMAIL1988年6月
client, one part of which read the mail and one part of which interacted with the repository. Although slightly cumbersome, the two-program setup works quite well.
クライアント、メールが読み込まれて、それの一部が倉庫と対話する一部。 わずかに厄介ですが、2プログラムのセットアップはかなりうまくいきます。
7.2. UNIX client code
7.2. UNIXクライアントコード
Client code for the Suns, Microvaxes, and VAX-750s runs on 4.2/4.3BSD UNIX. It is fully interactive, with a powerful mail reader inside Richard Stallman's GNU-EMACS editor. Since UNIX-based workstations have a good deal of main memory and disk storage, no effort was made to lower local mail state size by keeping message descriptors rather than message text.
サンズ、Microvaxes、およびVAX-750sのためのクライアントコードは4.2/4.3BSD UNIXで動きます。 それはリチャード・ストールマンのGNU-Emacsエディタの中で強力なメール読者と完全に対話的です。 以来、UNIXベースのワークステーションには、多くの主記憶装置とディスクストレージがあって、取り組みは、全くメッセージ・テキストよりむしろメッセージ記述子を保つことによって、地方のメール州のサイズを下げさせられませんでした。
The local mail state consists of a number of BABYL-format mailboxes. The interface is very similar to the RMAIL mail reader already present in GNU-EMACS.
地方のメール状態は多くのBABYL-形式メールボックスから成ります。 インタフェースはGNU-Emacsで既に出席しているRMAILメール読者と非常に同様です。
The mail reader communicates with the repository through network code implemented in EMACS-LISP. Changes to the local mail state are immediately made on the repository; although the repository is fast, there is a small noticeable delay in performing operations over the network.
メール読者はEmacs LISPで実装されたネットワークコードを通って倉庫で交信します。 地方のメール状態への変更はすぐに、倉庫の上で行われます。 倉庫は速いのですが、ネットワークの上の操作を実行する小さいめぼしい遅れがあります。
There is no provision for automatic synchronization whenever new mail arrives or old mail is changed by another client. Instead, users must get any new mail explicitly. A simple "notification" program runs in the background and wakes up every minute to check for new mail; when mail arrives, the user executes a command to get the new mail, synchronizing the mailbox at the same time.
新しいメールが到着するか、または古いメールが別のクライアントによって変えられるときはいつも、自動同期への支給が全くありません。 代わりに、ユーザは明らかにどんな新しいメールも受け取らなければなりません。 簡単な「通知」プログラムはバックグラウンドに逮捕して、毎分、目覚めて、新しいメールがないかどうかチェックします。 メールが到着するとき、同時にメールボックスを連動させて、ユーザは新しいメールを受け取るコマンドを実行します。
7.3. Repository code
7.3. 倉庫コード
The repository is implemented in C on 4.2/4.3BSD UNIX. Currently it runs on DEC VAX-750s and Microvaxes, although other repositories will soon be running on IBM RT machines and Sun workstations. The repository code is designed to allow several clients belonging to a particular user to "concurrently" modify the user's state. A locking scheme prevents one client from modifying mail state while another client is modifying the same state.
倉庫は4.2/4.3BSD UNIXの上でCで実装されます。 DEC VAX-750sとMicrovaxesの上で作業します、他の倉庫はすぐ、IBM RTマシンとSunワークステーションで動くでしょうが。 倉庫コードは、特定のユーザのものである数人のクライアントが「同時に」ユーザの状態を変更するのを許容するように設計されています。 ロック体系によって、別のクライアントが同じ状態を変更している間、1人のクライアントはメール状態を変更できません。
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 an efficient means of storing and maintaining mail state for several users. Its performance is quite good when up to ten users are connected; it remains to be seen whether or not the repository will be efficient at managing the state of ten or a
Pcmailは現在、MITコンピュータサイエンス研究所で人々の小規模地域社会によって使用されます。 数人のユーザのためにメール状態を保存して、維持する効率的な手段を提供して、倉庫デザインはうまくいきます。 最大10人のユーザが接続されているとき、性能はかなり良いです。 倉庫が10かaの状態を経営するところで効率的になるかどうかがまだ不明です。
Lambert [Page 26] RFC 1056 PCMAIL June 1988
ランバート[26ページ]RFC1056PCMAIL1988年6月
hundred times that many users. Given sufficient disk storage, it should be able to, since communication between different users' clients and the repository is likely to be very asynchronous and likely to occur in short bursts with long "quiet intervals" in between as users are busy doing other things.
多くのそのユーザの100倍。 十分なディスクストレージを考えて、できます、異なったユーザのクライアントと倉庫とのコミュニケーションが非常に非同期であって、ありそうである傾向があるので、ユーザが他のことをすることで忙しいときに、要するに、起こるのが中間で長い「静かな間隔」で充満するということであるべきです。
Members of another research group at LCS are currently working on a replicated, scalable 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 usable over several flavors of repository design.
LCSの別の研究グループのメンバーは現在、高い有用性でユーザの非常に大きい共同体をサポートするように設計された倉庫の模写されて、スケーラブルなバージョンに取り組んでいます。 この倉庫も、DMSPを使用して、首尾よく現在の倉庫実装を使用するクライアントと交信しました。 したがって、DMSPは、倉庫デザインのいくつかの風味の上で使用可能であるように思えます。
The IBM PC clients are very limited in the way of resources. The mail reader/editor combination is quite powerful, making local mail state manipulation fairly easy. Obviously a big performance enhancement would be to provide a fully interactive client. As it is, batch-style synchronization is relatively time consuming due to the low performance of the PCs. The "batch-mode" that the PCs use tends to be good for those PCs that spend a large percentage of their time unplugged and away from a network. It is somewhat inconvenient for those PCs that are always connected to a network and could make good use of an "interactive-mode" state manipulation.
IBMのPCクライアントはリソースの方法で非常に限られています。 地方のメール州の操作をかなり簡単にして、メール読者/エディタ組み合わせはかなり強力です。 明らかに、大きいパフォーマンス強化は完全に対話的なクライアントを提供するだろうことです。 それはそうであり、バッチはスタイルです。同期はPCの低性能のために比較的時間がかかっています。 PCが使用する「バッチ・モード」は、それらの時間アンプラグドの大きな割合とネットワークから遠くで費やされるそれらのPCに良い傾向があります。 それは、いつもネットワークに接続されるそれらのPCにいくらか不便であり、有効に「会話型」州の操作を利用するかもしれません。
The UNIX-based clients are more powerful and easier to use than their PC counterparts. Synchronization is much faster, and there is far more functionality in the mail reader (having an interface that runs within GNU-EMACS helps a lot in this respect). Most of those people using the Pcmail system use the UNIX-based client code.
UNIXベースのクライアントは、彼らのPC対応者よりさらに強力であって、使用しやすいです。 同期ははるかに速いです、そして、はるかに多くの機能性がメール読者にあります(GNU-Emacsの中で稼働するインタフェースを持っているのははるかにこの点で助けます)。 Pcmailシステムを使用しているそれらの人々の大部分はUNIXベースのクライアントコードを使用します。
Lambert [Page 27] RFC 1056 PCMAIL June 1988
ランバート[27ページ]RFC1056PCMAIL1988年6月
I. DMSP Protocol Specification
I. DMSPプロトコル仕様
Following are a list of DMSP operations by object type, together with syntax, and possible responses. Some responses may be followed by zero or more lines of text, terminated by a single period plus CR-LF pair. Only success responses and common error responses are listed; a complete list of possible responses follows this appendix. Expressions in angle brackets (i.e. <mailbox-name>) are metalinguistic variables indicating a general request or response form. Operations with arguments have a sample invocation following the operation syntax and response.
以下に、オブジェクト・タイプによるDMSP操作のリストが構文、および可能な応答と共にあります。 ゼロがいくつかの応答のあとに続くかもしれませんか、またはテキストの、より多くの系列でありただ一つの期間までにそのうえ、終えられて、CR-LFは対にします。 成功応答と一般的な誤り応答だけが記載されています。 可能な応答に関する全リストはこの付録に従います。 角ブラケット(すなわち、<メールボックス名の>)の式は一般的な要求か応答書式を示す超言語変数です。 議論による操作には、操作構文と応答に従って、サンプル実施があります。
General operations:
一般操作:
HELP
100 Repository version xxx. Following are supported:
HELP
SEND-VERSION
SEND-MESSAGE
LOGIN
LOGOUT
...
FETCH-MESSAGE
COPY-MESSAGE
.
ヘルプ100、Repositoryバージョンxxx。 次の事柄はサポートされます: バージョンを発信させているメッセージを発信させているログインがログアウトするのを助けてください… フェッチメッセージコピーメッセージ。
SEND-VERSION <version-number>
200 Command OK
500 version skew!
>200Command OK500バージョンが歪曲するSEND-バージョン<バージョン番号!
i.e. SEND-VERSION 230
すなわち、SEND-バージョン230
SEND-MESSAGE
350 enter message; end with "."
To: markl
From: markl
Subject: a test message
SEND-MESSAGE350はメッセージを入力します。 「終わる」、」 To: markl From: markl Subject: テストメッセージ
this is a test message
.
これはテストメッセージです。
Lambert [Page 28] RFC 1056 PCMAIL June 1988
ランバート[28ページ]RFC1056PCMAIL1988年6月
Repository responds:
倉庫は応じます:
200 Command OK
403 message syntax error
200 コマンドOK403メッセージ構文エラー
User operations:
ユーザ操作:
LOGIN <user> <password> <client> <create-p> <batch-p>
200 Command OK
221 Client out of date by > 1 week
404 Bad password
405 Client <client-name> is locked
411 No user named <user-name>
421 Client <client-name> not found
1週間の>404Badパスワード405Client<クライアント名の>で時代遅れのLOGIN<ユーザ><パスワード><p><バッチpを作成しているクライアント><>200Command OK221Clientは>が見つけなかった<ユーザ名>421Client<クライアント名という固定411いいえユーザです。
i.e. LOGIN markl foo random-client-name 1 0
すなわち、LOGIN markl foo無作為のクライアント名の1 0
LOGOUT
200 Command OK
ログアウト、200はOKを命令します。
SET-PASSWORD <old-password> <new-password>
200 Command OK
404 Incorrect old password
古いパスワードのSET-PASSWORDの<新しいパスワードの>200Command<>OK404のIncorrectの古いパスワード
i.e. SET-PASSWORD foo bar
すなわち、SET-PASSWORD fooバー
Client operations:
クライアント操作:
LIST-CLIENTS
220 Client list <name> <status> follows:
client-1 active
client-2 inactive
client-3 active
...
client-foobar active
.
LIST-CLIENTS220Clientリスト<名前><状態>は続きます: クライアント-1のアクティブなクライアント-2不活発なクライアント-3アクティブな…クライアント-foobarアクティブです。
Each line of the list contains a client name, followed by
whitespace, followed by the word "active" or the word "inactive",
indicating whether or not the client has connected to the repository
within the last week.
リストの各系列はクライアント名を含んでいます、続いてクライアントが最後の週中に倉庫に接続したかどうかを示す空白を含みます、続いて、「アクティブである」という言葉か「不活発である」という言葉を含みます。
Lambert [Page 29] RFC 1056 PCMAIL June 1988
ランバート[29ページ]RFC1056PCMAIL1988年6月
CREATE-CLIENT <client-name>
200 Command OK
403 <client-name> is an illegal name
420 Client <client-name> exists
CREATE-CLIENT<クライアント名>200のCommand OK403<クライアント名の>は420Client<が>にクライアントと同じくらい挙げる不法な名前が存在しているということです。
i.e. CREATE-CLIENT new-client
すなわち、CREATE-CLIENTの新しいクライアント
DELETE-CLIENT <client-name>
200 Command OK
421 Client <client-name> not found
405 Client <client-name> is locked
>200Command OK421Client<クライアント名の>が405Client<クライアント名の>を見つけなかったDELETE-CLIENT<クライアント名はロックされます。
i.e. DELETE-CLIENT old-client
すなわち、DELETE-CLIENTの年取ったクライアント
RESET-CLIENT <client-name>
200 Command OK
421 Client <client-name> not found
405 Client <client-name> is locked
>200Command OK421Client<クライアント名の>が405Client<クライアント名の>を見つけなかったRESET-CLIENT<クライアント名はロックされます。
i.e. RESET-CLIENT any-old-client
すなわち、どんなRESET-CLIENTの年取ったクライアント
Mailbox operations:
メールボックス操作:
LIST-MAILBOXES
230 Mbox list <name> <high-UID> <#msgs> <#new> follows:
mailbox-1 2338 8 1
mailbox-2 59 44 0
...
mailbox-foobar 19 9 0
.
LIST-MAILBOXES230Mboxリスト<名の>の高いUIDの><#msgs><<#新しい>は続きます: 0が…メールボックスでfoobarする2338年のメールボックス-1 8 1メールボックス-2 59 44、19、9 0
Each line of the list contains a mailbox name, followed by the
mailbox's next available unique identifier, followed by the number of
messages in the mailbox, followed finally by the number of unseen
messages in the mailbox. Unseen messages are those whose descriptors
have flag #1 ("message has been seen") set to zero.
リストの各系列はメールボックス名を含んでいます、続いてメールボックスの次の利用可能なユニークな識別子を含みます、続いて、メールボックスの中の見えないメッセージの数が最終的にあとに続いたメールボックスの中のメッセージの数を含みます。 見えないメッセージは記述子で、旗の#1(「メッセージを見られた」)をゼロに設定するそれらです。
CREATE-MAILBOX <mailbox-name>
200 Command OK
403 <mailbox-name> is an illegal name
430 <mailbox-name> already exists
440 <mailbox-name> exists as a bboard subscription
CREATE-MAILBOX <mailbox-name> 200 Command OK 403 <mailbox-name> is an illegal name 430 <mailbox-name> already exists 440 <mailbox-name> exists as a bboard subscription
Lambert [Page 30] RFC 1056 PCMAIL June 1988
Lambert [Page 30] RFC 1056 PCMAIL June 1988
i.e. CREATE-MAILBOX current-events
i.e. CREATE-MAILBOX current-events
DELETE-MAILBOX <mailbox-name>
200 Command OK
431 mailbox <mailbox-name> not found
440 <mailbox-name> is a bboard; use delete-bboard-mailbox
DELETE-MAILBOX <mailbox-name> 200 Command OK 431 mailbox <mailbox-name> not found 440 <mailbox-name> is a bboard; use delete-bboard-mailbox
i.e. DELETE-MAILBOX income-tax-information
i.e. DELETE-MAILBOX income-tax-information
CREATE-BBOARD-MAILBOX <mailbox-name>
200 Command OK
430 a mailbox named <mailbox-name> already exists.
430 a bboard mailbox named <mailbox-name> already exists.
403 <mailbox-name> is an illegal name
CREATE-BBOARD-MAILBOX <mailbox-name> 200 Command OK 430 a mailbox named <mailbox-name> already exists. 430 a bboard mailbox named <mailbox-name> already exists. 403 <mailbox-name> is an illegal name
i.e. CREATE-BBOARD-MAILBOX sf-lovers
i.e. CREATE-BBOARD-MAILBOX sf-lovers
DELETE-BBOARD-MAILBOX <mailbox-name>
200 Command OK
404 not owner of <mailbox-name>
431 no bboard mailbox named <mailbox-name>
DELETE-BBOARD-MAILBOX <mailbox-name> 200 Command OK 404 not owner of <mailbox-name> 431 no bboard mailbox named <mailbox-name>
i.e. DELETE-BBOARD-MAILBOX rec.autos
i.e. DELETE-BBOARD-MAILBOX rec.autos
RESET-MAILBOX <mailbox-name>
200 Command OK
431 mailbox <mailbox-name> not found
RESET-MAILBOX <mailbox-name> 200 Command OK 431 mailbox <mailbox-name> not found
i.e. RESET-MAILBOX british-cars
i.e. RESET-MAILBOX british-cars
EXPUNGE-MAILBOX <mailbox-name>
200 Command OK
431 mailbox <mailbox-name> not found
EXPUNGE-MAILBOX <mailbox-name> 200 Command OK 431 mailbox <mailbox-name> not found
EXPUNGE-MAILBOX british-cars
EXPUNGE-MAILBOX british-cars
Address operations:
Address operations:
LIST-ADDRESSES <mailbox-name>
260 Address list for <mailbox-name> follows:
address-1
LIST-ADDRESSES <mailbox-name> 260 Address list for <mailbox-name> follows: address-1
Lambert [Page 31] RFC 1056 PCMAIL June 1988
Lambert [Page 31] RFC 1056 PCMAIL June 1988
address-2
...
address-6
.
address-2 ... address-6 .
or
or
431 mailbox <mailbox-name> not found
431 mailbox <mailbox-name> not found
i.e. LIST-ADDRESSES archive
i.e. LIST-ADDRESSES archive
Each line of the list consists solely of one address.
Each line of the list consists solely of one address.
CREATE-ADDRESS <mailbox-name> <address-name>
200 Command OK
403 <mailbox-name> is an illegal name
431 mailbox <mailbox-name> not found
460 <address-name> already exists
CREATE-ADDRESS <mailbox-name> <address-name> 200 Command OK 403 <mailbox-name> is an illegal name 431 mailbox <mailbox-name> not found 460 <address-name> already exists
i.e. CREATE-ADDRESS markl markl-bug-pcmail
i.e. CREATE-ADDRESS markl markl-bug-pcmail
DELETE-ADDRESS <mailbox-name> <address-name>
200 Command OK
431 mailbox <mailbox-name> not found
461 address <address-name> not found
DELETE-ADDRESS <mailbox-name> <address-name> 200 Command OK 431 mailbox <mailbox-name> not found 461 address <address-name> not found
i.e. DELETE-ADDRESS markl markl-info-cobol
i.e. DELETE-ADDRESS markl markl-info-cobol
Subscription operations:
Subscription operations:
LIST-SUBSCRIPTIONS
240 subscription list follows:
bboard-1 2573 33 2606
bboard-2 541 4 545
...
bboard-6 1530 43 1573
.
LIST-SUBSCRIPTIONS 240 subscription list follows: bboard-1 2573 33 2606 bboard-2 541 4 545 ... bboard-6 1530 43 1573 .
Each line of the list consists of a bulletin-board name, followed by the UID of the first message which the user has not yet looked at, followed by the number of messages in the bulletin-board that the user has not yet looked at, followed by the bulletin-board's next available unique message identifier.
Each line of the list consists of a bulletin-board name, followed by the UID of the first message which the user has not yet looked at, followed by the number of messages in the bulletin-board that the user has not yet looked at, followed by the bulletin-board's next available unique message identifier.
Lambert [Page 32] RFC 1056 PCMAIL June 1988
Lambert [Page 32] RFC 1056 PCMAIL June 1988
CREATE-SUBSCRIPTION <bboard-name>
200 Command OK
403 <bboard-name> is an illegal name
430 A mailbox named <bboard-name> already exists
431 Bboard mailbox <bboard-name> not found
440 Already subscribing to <bboard-name>
CREATE-SUBSCRIPTION <bboard-name> 200 Command OK 403 <bboard-name> is an illegal name 430 A mailbox named <bboard-name> already exists 431 Bboard mailbox <bboard-name> not found 440 Already subscribing to <bboard-name>
i.e. CREATE-SUBSCRIPTION sf-lovers
i.e. CREATE-SUBSCRIPTION sf-lovers
DELETE-SUBSCRIPTION <bboard-name>
200 Command OK
441 Subscription <bboard-name> not found
DELETE-SUBSCRIPTION <bboard-name> 200 Command OK 441 Subscription <bboard-name> not found
i.e. DELETE-SUBSCRIPTION rec.music
i.e. DELETE-SUBSCRIPTION rec.music
RESET-SUBSCRIPTION <bboard-name> <new-UID>
200 Command OK
441 Subscription <bboard-name> not found
RESET-SUBSCRIPTION <bboard-name> <new-UID> 200 Command OK 441 Subscription <bboard-name> not found
i.e. RESET-SUBSCRIPTION rec.music.gdead 1210
i.e. RESET-SUBSCRIPTION rec.music.gdead 1210
LIST-AVAILABLE-SUBSCRIPTIONS
241 All available bboards follow:
mod.politics
sfl
tcp-ip
forum
...
comp.emacs
.
LIST-AVAILABLE-SUBSCRIPTIONS 241 All available bboards follow: mod.politics sfl tcp-ip forum ... comp.emacs .
Each line of the list consists solely of one bulletin-board
name.
Each line of the list consists solely of one bulletin-board name.
Message operations:
Message operations:
FETCH-CHANGED-DESCRIPTORS <mailbox-name> <max-to-send>
250 Descriptor list follows:
expunged
2333
expunged
2334
FETCH-CHANGED-DESCRIPTORS <mailbox-name> <max-to-send> 250 Descriptor list follows: expunged 2333 expunged 2334
Lambert [Page 33] RFC 1056 PCMAIL June 1988
Lambert [Page 33] RFC 1056 PCMAIL June 1988
descriptor
2337 0001000001110000 481 14
croaker@ptt.lcs.mit.edu
fred@anymachine.mit.edu
Tue, 19 Jan 88 11:10:03 EST
a typical subject line
descriptor
2339 0000000000000000 1457 40
bob@lcs.mit.edu
csr-people@ptt.lcs.mit.edu
Mon, 18 Jan 88 13:08:17 +0000
another typical subject line
expunged
2340
.
descriptor 2337 0001000001110000 481 14 croaker@ptt.lcs.mit.edu fred@anymachine.mit.edu Tue, 19 Jan 88 11:10:03 EST a typical subject line descriptor 2339 0000000000000000 1457 40 bob@lcs.mit.edu csr-people@ptt.lcs.mit.edu Mon, 18 Jan 88 13:08:17 +0000 another typical subject line expunged 2340 .
or
or
431 mailbox <mailbox-name> not found
431 mailbox <mailbox-name> not found
i.e. FETCH-CHANGED-DESCRIPTORS markl 100
i.e. FETCH-CHANGED-DESCRIPTORS markl 100
Each element of the descriptor list is either two or six lines long. Descriptors which have been expunged are transmitted as two lines: the word "expunged" on one line, followed by the message unique identifier on the next line. Descriptors which still exist are transmitted as six lines: the word "descriptor" on one line, followed by a line containing the message unique identifier, flag states (sixteen characters either one or zero depending on the associated flag value), followed by the message length in characters, followed by the message length in lines. The next four lines contain the message's "from:", "to:", "date:", and "subject:" fields, respectively. Flag zero's state is the first character in the flag string; flag fifteen's is the last character in the flag string.
Each element of the descriptor list is either two or six lines long. Descriptors which have been expunged are transmitted as two lines: the word "expunged" on one line, followed by the message unique identifier on the next line. Descriptors which still exist are transmitted as six lines: the word "descriptor" on one line, followed by a line containing the message unique identifier, flag states (sixteen characters either one or zero depending on the associated flag value), followed by the message length in characters, followed by the message length in lines. The next four lines contain the message's "from:", "to:", "date:", and "subject:" fields, respectively. Flag zero's state is the first character in the flag string; flag fifteen's is the last character in the flag string.
FETCH-DESCRIPTORS <mailbox-name> <low-uid> <high-uid>
250 Descriptor list follows:
descriptor
2337 0001000001110000 481 14
croaker@ptt.lcs.mit.edu
fred@anymachine.mit.edu
Tue, 19 Jan 88 11:10:03 EST
a typical subject line
descriptor
2339 0000000000000000 1457 40
bob@lcs.mit.edu
csr-people@ptt.lcs.mit.edu
FETCH-DESCRIPTORS <mailbox-name> <low-uid> <high-uid> 250 Descriptor list follows: descriptor 2337 0001000001110000 481 14 croaker@ptt.lcs.mit.edu fred@anymachine.mit.edu Tue, 19 Jan 88 11:10:03 EST a typical subject line descriptor 2339 0000000000000000 1457 40 bob@lcs.mit.edu csr-people@ptt.lcs.mit.edu
Lambert [Page 34] RFC 1056 PCMAIL June 1988
Lambert [Page 34] RFC 1056 PCMAIL June 1988
Mon, 18 Jan 88 13:08:17 +0000
another typical subject line
.
Mon, 18 Jan 88 13:08:17 +0000 another typical subject line .
or
or
431 mailbox <mailbox-name> not found
431 mailbox <mailbox-name> not found
i.e. FETCH-DESCRIPTORS british-cars 12 31
i.e. FETCH-DESCRIPTORS british-cars 12 31
COPY-MESSAGE <src-mailbox> <target-mailbox> <source-UID>
250 Descriptor list follows:
descriptor
2339 0000000000000000 1457 40
bob@lcs.mit.edu
csr-people@ptt.lcs.mit.edu
Mon, 18 Jan 88 13:08:17 +0000
another typical subject line
.
COPY-MESSAGE <src-mailbox> <target-mailbox> <source-UID> 250 Descriptor list follows: descriptor 2339 0000000000000000 1457 40 bob@lcs.mit.edu csr-people@ptt.lcs.mit.edu Mon, 18 Jan 88 13:08:17 +0000 another typical subject line .
or
or
400 cannot copy message onto itself
431 target mailbox <target-mailbox> not found
431 source mailbox <source-mailbox> not found
451 message <source-UID> not found
400 cannot copy message onto itself 431 target mailbox <target-mailbox> not found 431 source mailbox <source-mailbox> not found 451 message <source-UID> not found
i.e. COPY-MESSAGE markl british-cars 2338
i.e. COPY-MESSAGE markl british-cars 2338
RESET-DESCRIPTORS <mailbox-name> <low-UID> <high-UID>
200 Command OK
431 mailbox <mailbox-name> not found
RESET-DESCRIPTORS <mailbox-name> <low-UID> <high-UID> 200 Command OK 431 mailbox <mailbox-name> not found
i.e. RESET-DESCRIPTORS markl 1 10000
i.e. RESET-DESCRIPTORS markl 1 10000
PRINT-MESSAGE <mailbox-name> <UID> <printer-ID>
200 Command OK
401 printer <printer-name> not found
431 mailbox <mailbox-name> not found
451 message <UID> not found
PRINT-MESSAGE <mailbox-name> <UID> <printer-ID> 200 Command OK 401 printer <printer-name> not found 431 mailbox <mailbox-name> not found 451 message <UID> not found
i.e. PRINT-MESSAGE markl 2433 pravda
i.e. PRINT-MESSAGE markl 2433 pravda
Lambert [Page 35] RFC 1056 PCMAIL June 1988
Lambert [Page 35] RFC 1056 PCMAIL June 1988
SET-MESSAGE-FLAG <mailbox-name> <UID> <flagnum> <state>
200 Command OK
431 mailbox <mailbox-name> not found
451 message <UID> not found
500 flag number <flag-number> out of range
SET-MESSAGE-FLAG <mailbox-name> <UID> <flagnum> <state> 200 Command OK 431 mailbox <mailbox-name> not found 451 message <UID> not found 500 flag number <flag-number> out of range
i.e. SET-MESSAGE-FLAG british-cars 23 0 1
i.e. SET-MESSAGE-FLAG british-cars 23 0 1
FETCH-MESSAGE <mailbox-name> <UID>
251 message follows:
From: markl@ptt.lcs.mit.edu
To: markl@ptt.lcs.mit.edu
Date: Sun, 17 Jan 88 11:11:11 EST
Subject: anything
FETCH-MESSAGE <mailbox-name> <UID> 251 message follows: From: markl@ptt.lcs.mit.edu To: markl@ptt.lcs.mit.edu Date: Sun, 17 Jan 88 11:11:11 EST Subject: anything
this is a sample of some
message text
.
this is a sample of some message text .
or
or
431 Mailbox <mailbox-name> not found
451 message <UID> not found
431 Mailbox <mailbox-name> not found 451 message <UID> not found
i.e. FETCH-MESSAGE current-events 495
i.e. FETCH-MESSAGE current-events 495
Lambert [Page 36] RFC 1056 PCMAIL June 1988
Lambert [Page 36] RFC 1056 PCMAIL June 1988
II. Operations by name
II. Operations by name
copy-message create-address create-bboard-mailbox create-client create-mailbox create-subscription delete-address delete-bboard-mailbox delete-client delete-mailbox delete-subscription expunge-mailbox fetch-changed-descriptors fetch-descriptors fetch-message help list-addresses list-available-subscriptions list-clients list-mailboxes list-subscriptions login logout print-message reset-client reset-descriptors reset-mailbox reset-subscription send-message send-version set-message-flag set-password
copy-message create-address create-bboard-mailbox create-client create-mailbox create-subscription delete-address delete-bboard-mailbox delete-client delete-mailbox delete-subscription expunge-mailbox fetch-changed-descriptors fetch-descriptors fetch-message help list-addresses list-available-subscriptions list-clients list-mailboxes list-subscriptions login logout print-message reset-client reset-descriptors reset-mailbox reset-subscription send-message send-version set-message-flag set-password
Lambert [Page 37] RFC 1056 PCMAIL June 1988
Lambert [Page 37] RFC 1056 PCMAIL June 1988
III. Responses by number
III. Responses by number
100 Pcmail repository version XXX; following are supported 200 Command OK 220 Client list <name> <status> follows: 221 Client out of date by > 1 week 230 Mailbox list <name> <high UID> <#msgs> <#new> follows: 240 Subscription list follows: 250 Descriptor list follows: 251 Message follows: 260 Address list follows: 350 enter message; end with "." 400 cannot copy message onto itself 410 already logged in 420 client <name> already exists 430 mailbox <name> already exists 430 bboard mailbox <name> already exists 440 subscription <name> already exists 460 address <name> already exists 411 no user named <name> 421 client <name> not found 431 mailbox <name> not found 441 subscription <name> not found 451 message <UID> not found 461 address <name> not found 402 internal error message 403 syntax error in outbound message 404 bad password or permission denied 405 mail state is temporarily in use by another client 406 please log in 500 operation syntax error or illegal argument
100 Pcmail repository version XXX; following are supported 200 Command OK 220 Client list <name> <status> follows: 221 Client out of date by > 1 week 230 Mailbox list <name> <high UID> <#msgs> <#new> follows: 240 Subscription list follows: 250 Descriptor list follows: 251 Message follows: 260 Address list follows: 350 enter message; end with "." 400 cannot copy message onto itself 410 already logged in 420 client <name> already exists 430 mailbox <name> already exists 430 bboard mailbox <name> already exists 440 subscription <name> already exists 460 address <name> already exists 411 no user named <name> 421 client <name> not found 431 mailbox <name> not found 441 subscription <name> not found 451 message <UID> not found 461 address <name> not found 402 internal error message 403 syntax error in outbound message 404 bad password or permission denied 405 mail state is temporarily in use by another client 406 please log in 500 operation syntax error or illegal argument
Lambert [Page 38]
Lambert [Page 38]
一覧
スポンサーリンク
