RFC993 日本語訳
0993 PCMAIL: A distributed mail system for personal computers. D.D.Clark, M.L. Lambert. December 1986. (Format: TXT=71725 bytes) (Obsoletes RFC0984) (Obsoleted by RFC1056) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group David D. Clark (MIT) Request for Comments: 993 Mark L. Lambert (MIT) Obsoletes: RFC-984 December 1986
コメントを求めるワーキンググループのデヴィッド・D.クラーク(MIT)Requestをネットワークでつないでください: 993 マークL.ランバート(MIT)は以下を時代遅れにします。 RFC-984 1986年12月
PCMAIL: A Distributed Mail System for Personal Computers
PCMAIL: パーソナルコンピュータの分配されたメールシステム
1. Status of this Document
1. このDocumentの状態
This document is a discussion of the Pcmail workstation-based distri- buted mail system. It is a revision of the design published in NIC RFC-984. The revision is based on discussion and comment from a variety of sources, as well as further research into the design of interactive Pcmail clients and the use of client code on machines other than IBM PCs. As this design may change, implementation of this document is not advised. Distribution of this memo is unlimit- ed.
このドキュメントはPcmailのワークステーションベースのdistri- butedメールシステムの議論です。 それはNIC RFC-984で発行されたデザインの改正です。 改正はさまざまなソースからの議論とコメント、および対話的なPcmailクライアントのデザインとIBM PC以外のマシンにおけるクライアントコードの使用のさらなる研究に基づいています。 このデザインが変化するとき、このドキュメントの実装は教えられません。 このメモの分配は「非-限界」教育です。
2. Introduction
2. 序論
Pcmail is a distributed mail system providing mail service to an ar- bitrary 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 per- manently connected to a network. It is also designed to offer disk- less workstations full mail service.
Pcmailはそのそれぞれが1台以上のワークステーションを所有しているユーザのar- bitrary番号に対するメールサービスを提供する分配されたメールシステムです。 Pcmailの動機はさまざまな異なったワークステーションに対する非常にフレキシブルなメールサービスを提供することです、IBM PCのような小さくて、リソースで限られたマシンから資源に富んだ(「リソース」が主としてプロセッサ速度と椎間腔であるところ)サンズやMicrovaxesのようなマシンまでパワーのねらいを定めて。 それは、まだ資源に富んだマシンにフルサービスを供給している間、リソースで限られたワークステーションに対する限られたサービスを提供するのを試みます。 マシンがマシンと同様にネットワークにまれに接続されるだけである状態でうまくいくのが意図している、-、manentlyはネットワークに接続しました。 また、それは、完全なメールサービスをディスクより少ないワークステーションに提供するように設計されています。
The system is divided into two halves. The first consists of a sin- gle entity called the "repository". The repository is a storage center for incoming mail. Mail for a Pcmail user can arrive exter- nally 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番目は「倉庫」と呼ばれる罪のgle実体から成ります。 倉庫は入って来るメールのためのストレージセンターです。 Pcmailユーザのためのメールが到着できる、インターネットからのexter- nally、内部的である、他の倉庫ユーザから。 また、倉庫は安定したコピーの各ユーザのメール状態を維持します(これは今後ユーザの「グローバルなメール状態」と呼ばれるでしょう)。 したがって、通常、倉庫は多量のディスクストレージがあるコンピュータです。
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
Pcmailの後半は1「クライアント」から成ります。 それぞれのPcmailユーザには、クライアント、通常シングルユーザーワークステーションの特殊活字の数字があるかもしれません。 クライアントはネットワークの上でユーザのグローバルなメール状態にアクセスする好意的な手段をユーザに提供します。 倉庫とユーザのクライアントとの相互作用をより効率的にしてください、と各クライアントが地方のコピーを主張する、それ
Clark & Lambert [Page 1] RFC 993 December 1986
クラークとランバート[1ページ]RFC993 1986年12月
user's global mail state, called the "local mail state". It is as- sumed 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.
「地方のメール状態」と呼ばれるユーザのグローバルなメール状態。 それがそうである、-、小さいパーソナルコンピュータ、いつも、ネットワーク(そしてしたがって、倉庫のグローバルなメール状態に)に近づく手段を持っているかもしれないというわけではないということによるとことであり、そのクライアントをsumedしました。 これは、地方の、そして、グローバルなメール州が絶えず同じでないかもしれないことを意味します、地方の、そして、グローバルなメール州の間の同期を必要にして。
Clients communicate with the repository via the Distributed Mail Sys-
tem 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 mes-
sage", "print a message", etc.). DMSP also provides special opera-
tions 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
state unchanged ). A client can be abruptly disconnected from the
repository without leaving inconsistent or damaged mail states.
DistributedメールSys- temプロトコル(DMSP)でクライアントは倉庫で交信します。 このプロトコルのための仕様は付録A.に載っています。したがって、倉庫はメール端サイトと貯蔵場所に加えてDMSPサーバです。 DMSPはメールの完全な操作操作(「メッセージを送っ」て、「mes賢人を削除し」て、「メッセージを印刷しますなど」)を提供します。 また、DMSPは、ユーザのグローバルなメール州と彼のクライアントの地方のメール州の間の簡単な同期を許容するために特別なオペラtionsを提供します。 DMSP操作がユーザのメール状態に影響する方法に特別の注意を向けました。 すべてのDMSP操作が失敗原子です(すなわち、それらは完全に成功するか、またはユーザのメール状態を変わりがないままにするために保証されます)。 矛盾したか破損しているメールを州に残さないで、倉庫からクライアントから突然に切断することができます。
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 ade- quate mail service without hampering its performance on more resource-rich workstations. Finally, all workstations have some com- mon characteristics that Pcmail should take advantage of. For in- stance, 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はade- quateメールサービスをこのようなマシンに提供できなければなりません。 最終的に、すべてのワークステーションには、Pcmailが利用するはずであるいくつかのcom- monの特性があります。 コネ姿勢において、ほとんどの人々がメールサービスに使用する様々な時分割されたシステムと比べて、ワークステーションはかなり安価です。 これは、人々が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
また、いくつかのワークステーションがまれにあるだけであるのも、可能です。
Clark & Lambert [Page 2] RFC 993 December 1986
クラークとランバート[2ページ]RFC993 1986年12月
connected to a network (and thus be able to communicate with the re- pository). The Pcmail design therefore allows two modes of communi- cation 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 manipu- late 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.
ネットワーク(その結果、再positoryとコミュニケートできる)に関連しています。 したがって、Pcmailデザインは倉庫とクライアントの間にcommuni陽イオンの2つのモードを許容します。 クライアントがいつもネットワークに接続されるとき、「会話型」は使用されています。 また、すぐにクライアントの地方のメール状態へのどんな変更も倉庫のグローバルなメール状態にします、そして、すぐに、倉庫からクライアントまでどんな入って来るメールも送ります。 「バッチ・モード」は珍しいアクセスを倉庫に持っているクライアントによって使用されます。 ユーザmanipu遅く、クライアントのローカルは局所的に状態、待ち行列に変化を郵送します。 クライアントが倉庫に接続されていた状態で次であるときに、変化は実行されます、そして、クライアントの地方のメール状態は倉庫のグローバルなメール状態と同期します。
Finally, the Pcmail design minimizes the effect of using a resource- poor workstation as a client. Mail messages are split into two parts: a "descriptor" and a "body". The descriptor is a capsule mes- sage 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 extreme- ly 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 bo- dies, it can always pull them over from the repository as storage be- comes available.
最終的に、Pcmailデザインはクライアントとしてリソースの不十分なワークステーションを使用するという効果を最小にします。 メール・メッセージは2つの部品に分けられます: 「記述子」と「ボディー。」 記述子は長さ(通常およそ100バイト)が実際のメッセージ長から独立しているカプセルmes賢人の概要です。 ボディーはRFC-822の標準のメッセージヘッダーを含む実際のメッセージ・テキストです。 クライアントには完全なセットのメッセージを保持できるくらいのストレージがないかもしれない間、通常、完全なセットの記述子を保持できます、その結果、少なくとも彼のメール状態の概要をユーザに提供します。 極端なly限りある資源をもっているクライアントに関しては、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実装
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 per- manent 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
典型的なマシン実行倉庫コードには、比較的強力なプロセッサと多量のディスクストレージがあります。 また、それがaであるに違いない、-、2つの理由によるmanentネットワークサイト。 まず最初に、クライアントは、ネットワークの上で倉庫で交信して、倉庫のいつでも利用可能な存在に依存します。 2番目に、倉庫ユーザにメールを送る人々が倉庫がいずれにもメールを受け取るために利用可能であることを当てにします。
Clark & Lambert [Page 3] RFC 993 December 1986
クラークとランバート[3ページ]RFC993 1986年12月
time.
時間。
The repository must perform several tasks. First, and most impor- tantly, 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 effi- ciently manage bboard mail, using a minimum of storage to store 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 com- municate between repository and client must be reliable and must pro- vide operations that (1) allow typical mail manipulation, and (2) support Pcmail's distributed nature by allowing efficient synchroni- zation 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). In- ternet 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.
倉庫はいくつかのタスクを実行しなければなりません。 1番目、およびほとんどのimpor- tantly、倉庫は効率的に潜在的に多くのユーザと彼らのメール州を経営しなければなりません。 複数のクライアントがグローバルなメール状態にアクセスして、地元のメール州をグローバルな状態に連動させるのを簡単にする方法でメールを確かに保存しなければなりません。 電子メールの大きいカテゴリが(bboards)、倉庫がそうするべきである掲示板によって表されるので、effi- cientlyはbboardメールを管理します、bboardに加入するどんなユーザもまだメールを読むことができる方法によるbboardメッセージを保存するのに最小ストレージを使用して。 2番目に、倉庫は効率的にクライアントとコミュニケートできなければなりません。 倉庫とクライアントの間でcom- municateに使用されるプロトコルが信頼できるに違いない、必須である、親、参照、(1)が典型的なメール操作を許す操作、および(2)は地方の、そして、グローバルなメール州の間に効率的なsynchroni- zationを許容するPcmailの分配された本質をサポートします。 3番目に、倉庫は倉庫の自身のユーザーコミュニティの外のソースからメールを処理できなければなりません(主要な外部の源はインターネットです)。 コネternetメールは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 re- ferred to by a user object. A user object consists of a unique name, a password (which the user's clients use to authenticate themselves to the repository before manipulating a global mail state), a list of "client objects" describing those clients belonging to the user, and a list of "mailbox objects".
Pcmailは世界をユーザの共同体に分割します。 各ユーザは、ユーザで反対するために再ferredされます。 ユーザオブジェクトはユニークな名前、パスワード(ユーザのクライアントがグローバルなメール状態を操る前に倉庫に自分たちを認証するのに使用する)、ユーザのものであるそれらのクライアントについて説明する「クライアントオブジェクト」のリスト、および「メールボックスオブジェクト」のリストから成ります。
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 communi- cate 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 synchroni- zation; the repository associates with every global state change a list of client objects corresponding to those clients which have not recorded the global change locally.
クライアントオブジェクトはユニークな名前と状態から成ります。 ユーザは彼が所有している各クライアントあたり1個のクライアントオブジェクトを持っています。 ユーザの顧客リストに対応するクライアントオブジェクトを持っていない場合、クライアントは倉庫で美味をcommuniすることができません。 したがって、クライアントオブジェクトは有効なクライアントを倉庫に特定する手段として機能します。 また、クライアントオブジェクトで、倉庫は地方の、そして、グローバルなメール州のsynchroni- zationを管理できます。 あらゆるグローバルな状態の倉庫関連はそれらのクライアントにとって、対応するクライアントオブジェクトのリストを変えます(局所的にグローバルな変化を記録していません)。
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 re- pository implementation). When an inactive client does connect to the repository, the repository notifies the client that it has been "reset". The repository resets a client by marking all messages in the user's mail state as having changed since the client last logged in. When the client next synchronizes with the repository, it will receive a complete copy of the repository's global mail state. A
クライアントの状態は、「アクティブである」か「不活発です」。 倉庫は不活発なクライアントをそれらのクライアントと定義します(セットの期間(現在の再pository実装における1週間)以内に倉庫に接続しません)。 不活発なクライアントが倉庫に接続するとき、倉庫は、それが「リセットされたこと」をクライアントに通知します。 倉庫は、クライアントが最後にログインして以来変化しているとしてユーザのメール状態のすべてのメッセージをマークすることによって、クライアントをリセットします。 次のクライアントが倉庫に連動すると、それは完本の倉庫のグローバルなメール状態を受けるでしょう。 A
Clark & Lambert [Page 4] RFC 993 December 1986
クラークとランバート[4ページ]RFC993 1986年12月
forced reset is performed on the assumption that enough global state changes occur in a week that the client would spend too much time performing an ordinary local state-global state synchronization.
無理矢理のリセットは十分なグローバルな州の変化がクライアントが普通の地方の州のグローバルな州の同期を実行するのにあまりに多くの時間を費やすだろう1週間後に起こるという前提に実行されます。
Messages are stored in mailboxes. Users can have an arbitrary 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 mail- boxes" or "bboard mailboxes". The repository uses bboard mailboxes to store bboard mail. Bboard mailboxes differ from ordinary mail- boxes 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 bboard object. The bboard object contains the name of the bboard, its owner (the user who owns the bboard mailbox where all the mes- sages are stored), and the UID of the first message not yet seen by the subscriber .
bboard加入者は彼がbboardオブジェクトを通して見たメッセージの動向をおさえます。 bboardオブジェクトはbboardの名前、所有者(すべてのmes賢人が保存されるbboardメールボックスを所有しているユーザ)、および加入者によってまだ見られていなかった最初のメッセージのUIDを含んでいます。
Users gain read-only access to a bboard by "subscribing" to it; they lose that access when they "unsubscribe" to it.
ユーザはそれに「申し込み」であることによって、bboardへのリード・オンリー・アクセスを獲得します。 それに「外す」とき、彼らはそのアクセスを失います。
Associated with each mailbox are an arbitrary number of message ob- jects. 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.
各メールボックスに関連づけられているのは、メッセージob- jectsの特殊活字の数字です。 2つの部品が各メッセージに細かく分けられます--NIC RFC-822メッセージヘッダーを含むメッセージ・テキスト自体であるメッセージ、および「ボディー」に関する役に立つ情報の概要を含む「記述子。」 所有メールボックスの次の利用可能なUIDに基づく単調に増加するUIDは各メッセージに割り当てられます。 各メールボックスには、それ自身のメールボックス名とユーザ名と共に倉庫の中でメッセージを唯一特定するUIDsのセットがあります。
Clark & Lambert [Page 5] RFC 993 December 1986
クラークとランバート[5ページ]RFC993 1986年12月
A descriptor holds the following information: the message UID, the message size in bytes and lines, four "useful" message header fields (the "date:", "to:", "from:", and "subject:" fields), and sixteen flags. These flags are given identifying numbers 0 through: 15. Eight of these flags are reserved for the repository's use. Some of these are actually used by the repository, while others are simply held for informational purposes. In the current repository implemen- tation these flags mark:
記述子は以下の情報を保持します: メッセージUID、バイト、系列、4つの「役に立つ」メッセージヘッダーフィールド(「日付:」 「以下への」「以下」、および「subject:」 分野)、および16におけるメッセージサイズは弛みます。 No.0を特定しながら、以下を通してこれらの旗を与えます。 15. これらの8個の旗が倉庫の使用のために予約されます。 これらの或るものは実際に倉庫によって使用されますが、他のものは情報の目的のために単に保持されます。 現在の倉庫implemen- tationでは、これらの旗は以下をマークします。
- (#0) whether it has been deleted
- (#0)、それは削除されました。
- (#1) whether the message 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 reserved for future use.
残っている8個の旗が今後の使用のために予約されます。
Descriptors serve as an efficient means for clients to get message information without having to waste time retrieving the message from the repository.
記述子はクライアントが倉庫からメッセージを検索しながら時間を浪費する必要はなくてメッセージ情報を得る効率的な手段として機能します。
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 iden- tification. Any message is uniquely identified by the triple (user- name, mailbox-name, message-UID). Any mailbox is uniquely identified by the pair (user-name, mailbox-name). Thus to send a message between two repository users, a user would address the message to (user-name, mailbox-name). The repository would deliver the message to the named user and mailbox, and assign it a UID based on the re- quested mailbox's next available UID.
「アドレスオブジェクト」はメールがインターネットメッセージで扱うRFC822スタイルを倉庫名に翻訳するための手段を倉庫に提供します。 倉庫はそれ自身の名前空間をメッセージiden- tificationに供給します。 三重(ユーザ名、メールボックス名、メッセージ-UID)によってどんなメッセージも唯一特定されます。 どんなメールボックスも組(ユーザ名、メールボックス名)によって唯一特定されます。 したがって、2人の倉庫ユーザの間にメッセージを送るために、ユーザは(ユーザ名、メールボックス名)にメッセージを扱うでしょう。 倉庫は、命名されたユーザとメールボックスにメッセージを提供して、再探索したメールボックスの次の利用可能なUIDに基づくUIDをそれに割り当てるでしょう。
In order to translate between RFC-822-style mail addresses and repo- sitory names, the repository maintains a list of address objects. Each address object is an association between an RFC-822-style ad- dress 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
メールが扱うRFC822スタイルとrepo- sitory名の間で翻訳するために、倉庫はアドレスオブジェクトのリストを維持します。 それぞれのアドレスオブジェクトは広告が服を着せるRFC822スタイルと(ユーザ名、メールボックス名)組との仲間です。 そしてメールがインターネットから到着するとき、倉庫が(ユーザ名、メールボックス名)組に受取人を翻訳するのにアドレスオブジェクトリストを使用できる。
Clark & Lambert [Page 6] RFC 993 December 1986
クラークとランバート[6ページ]RFC993 1986年12月
route the message correctly.
正しくメッセージを発送してください。
4. Communication between repository and client: DMSP
4. 倉庫とクライアントとのコミュニケーション: DMSP
The Distributed Mail System Protocol (DMSP) is a block-stream proto- col that defines and manipulates the objects mentioned in the previ- ous section. It has been designed to work with Pcmail's single- repository/multiple-client model of the world. In addition to pro- viding typical mail manipulation functions, DMSP provides functions that allow easy synchronization of global and local mail states.
DistributedメールSystemプロトコル(DMSP)は、それが定義する岩塊流protoあん部であり、previ- ous部で言及されたオブジェクトを操作します。 それは、Pcmailの世界の独身の複数の倉庫/クライアントモデルと共に働くように設計されています。 親参照の典型的なメールマニピュレーション機能に加えて、DMSPはグローバルで地方のメール州の簡単な同期を許容する機能を提供します。
DMSP is implemented on top of the Unified Stream Protocol (USP),
specified in MIT-LCS RFC-272. USP provides a reliable virtual cir-
cuit block-stream connection between two machines. It defines a
basic set of data types ("strings", "integers", "booleans", etc.);
instances of these data types are grouped in an application-defined
order to form USP blocks. Each USP block is defined by a numeric
"block type"; a USP application can thus interpret a block's contents
based on knowledge of the block's type. DMSP consists of a set of
operations, each of which is comprised of one or more different USP
blocks that are sent between repository and client.
DMSPはMIT-LCS RFC-272で指定されたUnified Streamプロトコル(USP)の上で実装されます。 USPは2台のマシンの間の頼もしい仮想のcir- cuit岩塊流接続を提供します。 それは基本的なセットのデータ型(「ストリング」、「整数」、「論理演算子」など)を定義します。 これらのデータ型のインスタンスはUSPブロックを形成するアプリケーションで定義された命令で分類されます。 それぞれのUSPブロックは数値「ゴシック体」によって定義されます。 その結果、USPアプリケーションはブロックのタイプに関する知識に基づくブロックのコンテンツを解釈できます。 DMSPは1セットの操作から成ります。それは倉庫とクライアントの間に送られる1つ以上の異なったUSPブロック以上からそれぞれ成ります。
A DMSP session proceeds as follows: a client begins the session with the repository by opening a USP connection to the repository's machine. The client then authenticates both itself and its user to the repository with a "login" operation. If the authentication is successful, the user performs an arbitrary number of DMSP operations before ending the session with a "logout" operation (at which time the connection is closed by the repository).
DMSPセッションは以下の通り続きます: クライアントは、倉庫のマシンにUSP接続を開くことによって、倉庫とのセッションを始めます。 そして、クライアントは「ログイン」操作がある倉庫にそれ自体とそのユーザの両方を認証します。 認証がうまくいくなら、「ログアウトしてください」という操作(接続はどの時に倉庫によって閉店させられるかの)とのセッションを終わらせる前に、ユーザはDMSP操作の特殊活字の数字を実行します。
Because DMSP can manipulate a pair of mail states (local and global) at once, it is extremely important that all DMSP operations are 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 can take one of two basic forms, based on two broad categories that all DMSP operations fall into. First, an operation can be a request to perform some mail state modification, in which case the repository will acknowledge the request with either an "ok" or a "failure" (in which case the reason for the failure is also returned). Second, an operation can be a re- quest for information, in which case the request is acknowledged by the repository's providing the information to the client. Operations such as "delete a message" fall into the first category; operations like "send a list of mailboxes" fall into the second category.
DMSPがすぐに1組のメール州(地方の、そして、グローバルな)を操ることができるので、すべてのDMSP操作が失敗原子であることは、非常に重要です。 どんなDMSP操作の失敗も一貫して、知られている状態の州に両方を残さなければなりません。 この理由で、明白な承認が操作創始者によって受けられない場合、DMSP操作は、失敗したように定義されます。 この承認はすべてのDMSP操作がなる2つの広いカテゴリに基づいて2つの基本的なフォームの1つを取ることができます。 まず最初に操作が何らかのメール州の変更を実行するという要求であるかもしれない、その場合、倉庫は「OK」か「失敗」のどちらかがある要求を承諾するでしょう(その場合、また、失敗の理由を返します)。 情報を求めて2番目に、操作が再探索であるかもしれない、その場合、倉庫が情報をクライアントに提供することによって、要求は承諾されます。 「メッセージを削除してください」などの操作は最初のカテゴリになります。 「メールボックスのリストを送ってください」のような操作は2番目のカテゴリになります。
Following is a general discussion of all the DMSP operations. The operations are broken down by type: general operations, user opera- tions, client operations, mailbox operations, address operations, bboard operations, and message operations.
以下に、すべてのDMSP操作の一般的な議論があります。 操作はタイプで砕けています: 一般的な操作(ユーザオペラtions、クライアント操作、メールボックス操作)は操作、bboard操作、およびメッセージ操作を扱います。
Clark & Lambert [Page 7] RFC 993 December 1986
クラークとランバート[7ページ]RFC993 1986年12月
4.1. General operations
4.1. 一般操作
The first group of DMSP operations perform general functions that operate on no one particular class of object. DMSP has two general operations, which provide the following services:
DMSP操作の最初のグループはオブジェクトのどんな1つの特定のクラスも経営しない一般的な機能を実行します。 DMSPには、2つの一般的な操作があります:(操作は以下のサービスを提供します)。
In order to prevent protocol version skew between clients and the re- pository, DMSP provides a "send-version" operation. The client sup- plies 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 ver- sion number is an unsigned quantity, like "100", "101", "200". The "send-version" operation should be the first that a client sends to the repository, since no other operation my work if the client and repository are using different versions of DMSP.
DMSPがクライアントと再positoryの間のプロトコルバージョン斜行を防ぐために提供する、「バージョンを発信させる、」 操作 クライアント一口は議論としてDMSPバージョン番号を運航します。 供給されたバージョン番号が倉庫のDMSPバージョン番号に合っているなら、操作は成功します。 2つのバージョン番号が合っていないなら、それは失敗します。 ver- sion番号は「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 on the "to:", "cc:", and "bcc:" fields of the message header. If one or more of the mailboxes exists outside the repository's user community, the repository is responsible for hand- ing the message to a local SMTP server.
を通してユーザが他のユーザにメールを送ることができる、「メッセージを発信させる、」 操作。 メッセージには、NIC RFC-822によって定義されるようにインターネットスタイルヘッダーがなければなりません。 倉庫は、伝言を受け取て、「以下のこと」、「cc:」、および「bcc:」で指定されたメールボックスにそれを分配します。 メッセージヘッダーの分野。 メールボックスの1つ以上が倉庫のユーザーコミュニティの外に存在しているなら、手がメッセージをingするので、倉庫はローカルのSMTPサーバーに原因となります。
An OK is sent from the repository only if the entire message was suc- cessfully transmitted. If the message was destined for the Internet, the send-message operation is successful if the message was success- fully transmitted to the local SMTP server.
全体のメッセージが伝えられたsuc- cessfullyであった場合にだけ倉庫からOKを送ります。 メッセージがインターネットに運命づけられたなら、メッセージを発信させている操作はメッセージがローカルのSMTPサーバーに完全に伝えられた成功であったならうまくいっています。
4.2. User operations
4.2. ユーザ操作
The next series of DMSP operations manipulates user objects. The most common of these operations are "login" and "logout". A client must perform a login operation before being able to access a user's mail state. A DMSP login block contains five items: (1) the user's name, (2) the user's password, (3) the name of the client performing the login, (4) a flag telling the repository to create a client ob- ject for the client if one does not exist, and (5) a flag set to TRUE if the client wishes to operate in "batch mode" and FALSE if the client wishes to operate in "interactive" mode. The flag value al- lows the repository to tune internal parameters for either mode of operation.
DMSP操作の次のシリーズはユーザオブジェクトを操作します。 これらの操作で最も変哲もないのは、「ログイン」であり、「ログアウトします」。 ユーザのメール状態にアクセスできる前に、クライアントはログイン操作を実行しなければなりません。 DMSPログインブロックは5つの項目を含んでいます: (1) クライアントが「対話的な」モードで作動したいなら(3) (2) ユーザのパスワード、(4) ログインを実行しているクライアント、旗の名前が、(5) クライアントの1つが存在していないか、そして、クライアントが「バッチ・モード」で作動したいならTRUEに用意ができている旗とFALSEのためにクライアントob- jectを作成するように倉庫に言うユーザの名前。 旗はアル安値を評価します。運転モードのための内部のパラメタを調整する倉庫。
The repository can return either an OK block (indicating successful authentication), a FAILURE block (indicating failed authentication), or a FORCE-RESET block. This last is sent if the client logging in has been marked as "inactive" by the repository (clients are marked inactive if they have not connected to the repository in over a week). The FORCE-RESET block indicates that the client should erase its local mail state and pull over a complete version of the repository's mail state. This is done on the assumption that so many
倉庫はOKブロック(うまくいっている認証を示す)、FAILUREブロック(失敗した認証を示す)、またはFORCE-RESETブロックを返すことができます。 倉庫のそばで「不活発である」としてログインしているクライアントをマークしたなら(彼らが1週間以上倉庫に接続しないなら、クライアントは不活発であるとマークされます)、最後にこれを送ります。 FORCE-RESETブロックは、クライアントが地方のメール状態を消して、倉庫のメール状態の完全なバージョンの上で引くべきであるのを示します。 とてもそんなに多い前提でこれをします。
Clark & Lambert [Page 8] RFC 993 December 1986
クラークとランバート[8ページ]RFC993 1986年12月
mail state changes have been made in a week that it would be ineffi- cient to perform a normal synchronization.
それがineffi- cientであるだろうことの1週間で、メール州の変更が通常の同期を実行すると行われました。
When a client has completed a session with the repository, it per- forms a logout operation. This allows the repository to perform any necessary cleanup before closing the USP connection.
フォームaはログアウトします。クライアントが倉庫とのセッションを終了したときそれ、-、操作。 これで、USP接続を終える前に、倉庫はどんな必要なクリーンアップも実行できます。
A user can change his password via the "set-password" operation. The operation works much the same as the UNIX change-password operation, taking as arguments the user's current password and a desired new password. If the current password given matches the user's current password, the user's current password is changed to the new password given.
ユーザは「セットパスワード」操作で彼のパスワードを変えることができます。 操作はUNIX変化パスワード操作への大体同じことを扱います、議論としてユーザの現在のパスワードと必要な新しいパスワードをみなして。 与えられた現在のパスワードがユーザの現在のパスワードに合っているなら、ユーザの現在のパスワードは与えられた新しいパスワードに変わります。
4.3. Client operations
4.3. クライアント操作
DMSP provides four operations to manipulate client objects. The first, "list-clients", tells the repository to send the user's client list to the requesting client. The list takes the form of a series of (client-name, status) pairs. The status is either 0 (inactive) or 1 (active).
DMSPは、クライアントオブジェクトを操作するために四則を提供します。 「リストクライアント」という1番目は、ユーザの顧客リストを要求しているクライアントに送るように倉庫に言います。 リストは一連の(クライアント名、状態)組の形を取ります。 状態は、どちらかの0(不活発な)か1(アクティブな)です。
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 add-client operation is a useful means of creating a number of new client ob- jects while logged into the repository via an existing client. The create-client operation requires the name of the client to add.
「クライアントを創造する、」 操作、ユーザが彼のクライアントオブジェクトのリストにクライアントオブジェクトを追加するのを許容します。 ログイン操作は「このクライアントを創造していますか?」の旗でこの機能性をコピーしますが、クライアントを加えている操作は既存のクライアントを通して倉庫に登録されている間、多くの新しいクライアントob- jectsを作成する役に立つ手段です。 クライアントを創造している操作は、加えるためにクライアントの名前を必要とします。
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.
「クライアントを削除する、」 操作はユーザの顧客リストから既存のクライアントオブジェクトを取り除きます。 外されているクライアントは当時だれでも使用中であるはずがありません。
The last client operation, "reset-client", causes the repository to mark all messages in the user's mail state as having changed since the client last logged in. When a client next synchronizes with the repository, it will end up receiving a complete copy of the repository's global mail state. This is useful for two reasons. First, a client's local mail state could easily become lost or dam- aged, 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 re- pository, 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番目に、クライアントが倉庫のそばで不活発であるとしてマークされたなら、リセットクライアント操作はとても多くの違いが地方の、そして、グローバルなメール州の間に存在しているので通常の同期が遠くに取り過ぎると仮定する再pository時間を再連動する速い方法に提供します。
4.4. Mailbox operations
4.4. メールボックス操作
DMSP supports five operations that manipulate mailbox objects. First, "list-mailboxes" has the repository send to the requesting client information on each mailbox. This information consists of the
DMSPはメールボックスオブジェクトを操作する5つの操作をサポートします。 まず最初に、「リストメールボックス」は倉庫をそれぞれのメールボックスの要求しているクライアント情報に発信させます。 この情報は成ります。
Clark & Lambert [Page 9] RFC 993 December 1986
クラークとランバート[9ページ]RFC993 1986年12月
mailbox name, total message count, unseen message count, and "next available UID". This operation is useful in synchronizing local and global mail states, since it allows a client to compare the user's global mailbox list with a client's local mailbox list. The list of mailboxes also provides a quick summary of each mailbox's contents without having the contents present.
メールボックス名、総メッセージカウント、見えないメッセージカウント、および「次の利用可能なUID。」 この操作は地方の、そして、グローバルなメール州を連動させる際に役に立ちます、クライアントがそれでクライアントのローカルのメールボックスリストとユーザのグローバルなメールボックスリストを比べることができるので。 また、コンテンツプレゼントを持っていなくて、メールボックスのリストは各メールボックスのコンテンツの短い概要を提供します。
The "create-mailbox" has the repository create a new mailbox and at- tach it to the user's list of mailboxes. An address object binding the (user-name, mailbox-name) pair to an RFC-822-style address is au- tomatically created and placed in the repository's list of address objects. This allows mail coming from the Internet to be correctly routed to the new mailbox.
そして、「メールボックスを作成する、」、倉庫に新しいメールボックスを作成させる、-、留め金、それ、ユーザのメールボックスのリストに。 RFC822スタイルへの(ユーザ名、メールボックス名)組が扱うアドレスオブジェクト結合は倉庫のアドレスオブジェクトのリストにtomaticallyに作成されて、置かれたAuです。 これは、インターネットから来るメールが正しく新しいメールボックスに発送されるのを許容します。
"Delete-mailbox" removes a mailbox from the user's list of mailboxes. All messages within the mailbox are also deleted and permanently re- moved from the system. Any address objects binding the mailbox name to RFC-822-style mailbox addresses are also removed from the system.
「メールボックスを削除する、」 ユーザのメールボックスのリストからメールボックスを取り外します。 メールボックスの中のすべてのメッセージが、また、削除されて、永久に、システムから再動かされます。 また、システムからRFC822スタイルメールボックスアドレスにメールボックス名を縛るどんなアドレスオブジェクトも取り除きます。
"Reset-mailbox" causes the repository to mark all the messages in a named mailbox as having changed since the current client last saw them. When the client next synchronizes with the repository, it will receive a complete copy of the named mailbox's mail state. This operation is merely a more specific version of the reset-client operation (which allows the client to pull over a complete copy of the user's global mail state). Its primary use is for mailboxes whose contents have accidentally been destroyed locally.
「リセットメールボックス」は倉庫に現在のクライアントが最後にそれらを見て以来変化しているとして命名されたメールボックスの中のすべてのメッセージをマークさせます。 次のクライアントが倉庫に連動すると、それは完本の命名されたメールボックスのメール状態を受けるでしょう。 この操作は単にリセットクライアント操作(クライアントは完本のユーザのグローバルなメール状態の上で引くことができる)の、より特定のバージョンです。 プライマリ使用は偶然局所的にコンテンツを破壊してあるメールボックスのためのものです。
Finally, DMSP has an "expunge-mailbox" operation. Any message can be deleted and "undeleted" at will. Deletions are made permanent by performing an expunge-mailbox operation. The expunge operation causes the repository to look through a named mailbox, removing from the system any messages marked "deleted".
最終的に、DMSPが持っている、「メールボックスを梢消する、」 操作。 どんなメッセージも自由自在に削除して、"非削除"であることができます。 メールボックスを梢消している操作を実行することによって、削除を永久的にします。 命名されたメールボックスに目を通して、システムからどんなメッセージも取り除くことへの倉庫が「削除されている」とマークした操作原因を梢消してください。
4.5. Address operations
4.5. アドレス操作
DMSP provides three operations that allow users to manipulate address objects. First, the "list-address" operation returns a list of ad- dress objects associated with a particular (user-name, mailbox-name) pair.
DMSPはユーザがアドレスオブジェクトを操作できる3つの操作を提供します。 まず最初に、「リストアドレス」操作は特定(ユーザ名、メールボックス名)の組に関連している広告ドレスオブジェクトのリストを返します。
The "create-address" operation adds a new address object that associ- ates a (user-name, mailbox-name) pair with a given RFC-822-style mailbox address.
「アドレスを作成する、」 操作、associ- ates a(ユーザ名、メールボックス名)が当然のことのRFC822スタイルメールボックスアドレスと対にする新しいアドレス物を加えます。
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.
最終的である、「アドレスを削除する、」 操作、与えられたRFC822スタイル郵便の宛先と与えられた(ユーザ名、メールボックス名)組を縛るアドレス物を破壊します。
Clark & Lambert [Page 10] RFC 993 December 1986
クラークとランバート[10ページ]RFC993 1986年12月
4.6. Bboard operations
4.6. Bboard操作
DMSP provides seven bulletin board operations. The first, "list- bboards", gives the user a list of the bboards he is currently sub- scribing to. The list contains an entry for each bboard that the user subscribes to. Each entry contains the following information:
DMSPは7つの掲示板の操作を提供します。 「リストbboards」という1番目は彼が現在サブ荷印刻み付けであるbboardsのリストをユーザに与えます。 リストはユーザが加入する各bboardのためのエントリーを含んでいます。 各エントリーは以下の情報を含んでいます:
- The bulletin board's name
- 掲示板の名前
- The UID of the first message the subscriber has not yet
seen
- 加入者がまだ見ていない最初のメッセージのUID
- The highest message UID in the bulletin board
- 掲示板の最も高いメッセージUID
- The number of messages the subscriber has not yet seen
- 加入者がまだ見ていないメッセージの数
"List-all-bboards" gives the user a list of all bboards he can sub- scribe to.
「リストオールbboards」は彼がそうすることができるすべてのbboardsのユーザaリストをサブ線を引くのに与えます。
"Create-bboard" allows a user to create a bboard mailbox. The name given must be unique across the entire repository user community. Once the bboard mailbox has been created, other users may subscribe to the bboard, using bboard objects to keep track of which messages they have read on which bboards.
「bboardを作成する、」 ユーザがbboardメールボックスを作成するのを許容します。 付与という名前は全体の倉庫ユーザーコミュニティの向こう側にユニークであるに違いありません。 bboardメールボックスがいったん作成されると、他のユーザはbboardに加入するかもしれません、動向をおさえるそれらがどのbboardsでそれのメッセージを読んだbboard物を使用して。
"Delete-bboard" 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.
「bboardを削除する、」 bboardの所有者がbboardメールボックスを削除するのを許容します。 それが削除された後にbboardメールボックスから読むのを試みる加入者はbboardがもう存在しないと言われます。
DMSP also provides operations to subscribe to, and unsubscribe from, any bboard. "Subscribe-bboard" adds a bboard object to the users bboard object list; "unsubscribe-bboard" removes a bboard object from the list. Note that this does not delete the bboard mailbox (obvi- ously only the bboard's owner can do that). It merely removes the user from the list of the bboard's subscribers.
また、DMSPは、どんなbboardからも申し込んで、外すために操作を提供します。 「-bboardに申し込んでください」はユーザbboard物のリストにbboard物を追加します。 「-bboardに外してください」はリストからbboard物を取り除きます。 これがbboardメールボックス(bboardだけの所有者がそれができるobvi- ously)を削除しないことに注意してください。 それはbboardの加入者のリストからユーザを単に外します。
DMSP allows for the user to tell the repository which messages in a bboard he has seen. Every bboard object contains the UID of the first message the user has not yet seen; the "set-first-unread- message-UID" operation updates that number, insuring that the user sees a given bboard message only once.
DMSPは、ユーザが、彼がbboardのどのメッセージを見たかを倉庫に言うのを許容します。 あらゆるbboard物がユーザがまだ見ていない最初のメッセージのUIDを含んでいます。 ユーザが一度だけ与えられたbboardメッセージを見るのを保障して、「最初にセット読まれていないメッセージ-UID」操作はその数をアップデートします。
4.7. Message operations
4.7. メッセージ操作
The most commonly-manipulated Pcmail objects are messages; DMSP therefore provides special message operations to allow efficient syn- chronization, as well as a set of operations to perform standard message-manipulation functions. In the following paragraphs, the terms "message" and "descriptor" will be used interchangeably.
最も多くの一般的に操られたPcmail物がメッセージです。 したがって、DMSPは、効率的なsyn- chronization、および1セットの操作が標準のメッセージマニピュレーション機能を実行するのを許容するために特別教書操作を提供します。 以下のパラグラフでは、用語「メッセージ」と「記述子」は互換性を持って使用されるでしょう。
A user may request a series of descriptors with the "get-descriptors"
ユーザが一連の記述子を要求するかもしれない、「記述子を得る、」
Clark & Lambert [Page 11] RFC 993 December 1986
クラークとランバート[11ページ]RFC993 1986年12月
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 se- quence of "choices". Elements of the sequence can either be descrip- tors, in which case the choice is tagged as a descriptor, or they can be notification that the requested message has been expunged subse- quent to the client's last connection to the repository. A descrip- tor choice is a record containing the message's UID, flags, to, from, date, and subject fields, length in bytes, and length in lines. An expunged choice contains only the expunged message's UID.
操作。 シリーズはリストの1組のメッセージUIDs、下側を表して、および上限によって特定されます。 UIDsが数を単調に増加させているように定義されるので、1組のUIDsは記述子のシリーズを完全に特定するために十分です。 下界UIDが存在していないなら、UIDが下界よりすばらしい状態で倉庫は最初のメッセージとのシリーズを始めます。 同様に、上限が存在していないなら、倉庫はUIDと共に上限より最後のメッセージとのシリーズを終わらせません。 シリーズの中のあるUIDsがもう存在していないなら、倉庫は(明らかに)それらを送りません。 倉庫は「選択」のse- quenceの記述子を返します。 系列のElementsがdescrip- torsであるかもしれない、その場合、選択は記述子としてタグ付けをされるか、それらが要求されたメッセージが倉庫とのクライアントの最後の接続への梢消されたsubse- quentであるという通知であるかもしれません。 descrip- tor選択はメッセージのUIDを含む記録です、旗、日付、対象の分野、バイトで表現される長さ、および並んでいる長さ。 梢消された選択は梢消されたメッセージだけのUIDを含んでいます。
The "get-changed-descriptors" operation is intended for use during state synchronization. Whenever a descriptor changes state (is deleted, for example), the repository notes those clients which have not yet recorded the change locally. Get-changed-descriptors has the repository send to the client a given number of descriptors which have changed since the client's last synchronization. The list sent begins with the earliest-changed descriptor. Note that the list of descriptors is only guaranteed to be monotonically increasing for a given call to "get-changed-descriptors"; messages with lower UIDs may be changed by other clients in between calls to "get-changed- descriptors".
「変えられた記述子を得てください」という操作は使用のために州の同期の間、意図します。 記述子が状態(例えば、削除される)を変えるときはいつも、倉庫はそれらのクライアントに注意します(まだ局所的に変化を記録していません)。 変えられた記述子を得てください。倉庫にクライアントのものが同期が続くので変化した与えられた数の記述子をクライアントに送らせます。 送られたリストは最も早く変えられた記述子で始まります。 記述子のリストが与えられた呼び出しのために「変えられた記述子を得てください」に単調に増加しているように保証されるだけであることに注意してください。 下側のUIDsがあるメッセージが間のコネが呼びかける他のクライアントによって変えられるかもしれない、「変えられた記述子を得る、」
Once the changed descriptors have been looked at, a user will want to inform the repository that the current client has recorded the change locally. The "reset-changed-descriptors" causes the repository to mark as "seen by current client" a given series of descriptors. The series is identified by a low UID and a high UID. UIDs within the series that no longer exist are not reset.
変えられた記述子がいったん見られると、ユーザは、現在のクライアントが局所的に変化を記録したことを倉庫に知らせたくなるでしょう。 「リセットの変えられた記述子」は、与えられたシリーズに関する記述子を「現在のクライアントで、見る」ので、マークへの倉庫を引き起こします。 シリーズは低いUIDと高いUIDによって特定されます。 もう存在しないシリーズの中のUIDsはリセットされません。
Message bodies are transmitted from repository to user with the "get-message-text" operation. The separation of "get-descriptors" and "get-message-text" operations allows clients with small amounts of disk storage to obtain a small message summary (via "get- descriptors" or "get-changed-descriptors") without having to pull over the entire message.
メッセージ本体が倉庫からユーザまで伝えられる、「メッセージ・テキストを得る、」 操作。 分離、「記述子を得る、」、「メッセージ・テキストを得る、」 操作で、少量のディスク格納のクライアントは小さいメッセージ要約(「記述子を得てください」か「変えられた記述子を得てください」を通した)のそうする必要はなくて牽引力を全体のメッセージの上に入手できます。
Frequently, a message may be too large for some clients to store lo- cally. Users can still look at the message contents via the "print- message" operation. This operation has the repository send a copy of the message to a named printer. The printer name need only have meaning to the particular repository implementation; DMSP transmits the name only as a means of identification.
頻繁に、メッセージは何人かのクライアントが最低気温警察署を格納できないくらい大きいかもしれません。 ユーザは「印刷メッセージ」操作でまだメッセージ内容を見ることができます。 この操作で、倉庫はメッセージのコピーを命名されたプリンタに送ります。 プリンタ名は特定の倉庫実現に意味を持つだけでよいです。 DMSPは単に識別の手段として名前を伝えます。
Clark & Lambert [Page 12] RFC 993 December 1986
クラークとランバート[12ページ]RFC993 1986年12月
Copying of one message into another mailbox is accomplished via the "copy-message" operation. A descriptor list of length one, contain- ing 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 containing the UID.
別のメールボックスの中に1つのメッセージをコピーするのは「コピーメッセージ」操作で実行されます。 記述子をリストアップします。長さ1では、コピー操作がうまくいくなら、コピーされたメッセージのための記述子が返されるingを含んでください。 コピーされたメッセージがオリジナルのメッセージと異なったUIDを獲得するので、この記述子が必要です。 クライアントが、したがって、コピー、倉庫がUIDを含む記述子を送るのをどのUIDに割り当ててあるかを知っていることを期待できません。
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 charac- teristics of these workstations. First, most workstations are much more affordable than the large computers currently used for mail ser- vice. It is therefore possible that a user may well have more than one. Second, some workstations are portable and they are not expect- ed to be constantly tied into a network. Finally, many of the small- er workstations resource-poor, so they are not expected to be able to store a significant amount of state information locally. The follow- ing subsections describe the particular parts of Pcmail's client ar- chitecture that address these different characteristics.
クライアントは異なったワークステーションの数のいずれであることができますも。 したがって、Pcmailの構造はこれらのワークステーションのcharac- teristicsの範囲を考慮に入れなければなりません。 まず最初に、ほとんどのワークステーションが現在メールser悪に使用されている大きいコンピュータよりはるかに手頃です。 したがって、ユーザには1つ以上がたぶんあるだろうというのは、可能です。 2番目、いくつかのワークステーションが携帯用です、そして、それらは携帯用です。ネットワークに結ばれて、絶えず教育は予想しません。 最終的に小ささの多く、えー、ワークステーション、資源の乏しいので、局所的にかなりの量の州の情報を格納できないと予想されます。 尾行ing小区分はこれらの異なった特性を記述するPcmailのクライアントar- chitectureの特定の部分について説明します。
5.1. Multiple clients
5.1. 複数のクライアント
The fact that Pcmail users may own more than one workstation forms the rationalization 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 restric- tions 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は同時に倉庫で数人のクライアントから交信するユーザの能力にrestric- tionsを全く置きません。 代わりに、倉庫実現でユーザのメール状態への同時発生のアクセスを数人のクライアントに許すという決定をします。
5.2. Synchronization
5.2. 同期
Some workstations tend to be small and fairly portable; the likeli- hood 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 lo- cal and global mail states. The repository is continually in a posi- tion to receive global mail state updates, either in the form of in- coming 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.
いくつかのワークステーションが、小さくて、かなり携帯用である傾向があります。 それらがいつもネットワークに関連していることのlikeliフードは比較的小さいです。 これは各クライアントが地方のコピーのユーザのメール状態を維持する別の理由です。 そして、ユーザはネットワーク(そして、倉庫)に関連づけられていない間、地方のメール状態を操ることができます。 これはすぐに、最低気温calとグローバルなメール州の間に同期の問題を持って来ます。 posi- tionでは、絶えず、グローバルなメールを受け取るのがアップデートを述べるということであるか倉庫はコネの次のメールの形、または他のクライアントからの変化の形でそうします。 いつもネットに接続されるというわけではないクライアントはすぐに、グローバルな変化を受けることができません。 さらに、クライアントのユーザは地方のメール状態で彼自身の変更を行うことができます。
Clark & Lambert [Page 13] RFC 993 December 1986
クラークとランバート[13ページ]RFC993 1986年12月
Pcmail's architecture allows fast synchronization between client lo- cal 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 in- clude 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の構造は郵便配達人が述べるcalと倉庫のグローバルなメール状態をクライアント最低気温の間の速い同期に許容します。 各クライアントは倉庫でユーザに愛着しているクライアント物によって特定されます。 この物は地方の、そして、グローバルなメール州の間で同期の基礎を形成します。 中のいくつかのそれほど一般的でない州の変化がアドレス物のユーザメールボックスの付加と削除、付加、および削除をcludeします。 これらの変化の同期はDMSPリスト操作で実行されます。(クライアントは、メールボックスとアドレス物のリストの地元のバージョンを倉庫のグローバルなバージョンにたとえて、操作でどんな適切な変更も行います)。 ユーザのメール状態への可能な変化の大部分が変えられた記述子の形にあります。 ほとんどのユーザには多くのメッセージがあって、メッセージ州が比較的しばしば変化するので、特別な注意は、メッセージ同期に支払われる必要があります。
An existing descriptor can be changed in one of two ways: first, one of its sixteen flags values can be changed (this encompasses reading an unseen message, deleting a message, and expunging a message). The second way to change a descriptor is via the arrival of incoming mail or the copying of a message from one mailbox to another. Both result in a new message being added to a mailbox.
2つの方法の1つで既存の記述子を変えることができます: まず最初に、変えることができます(これが見えないメッセージを読むメッセージを削除するのを取り囲んで、メッセージを梢消して)16個の旗のひとりが、評価する。 入って来るメールの到着かメッセージの1個のメールボックスから別のメールボックスまでのコピーを通して記述子を変える2番目の方法があります。 両方がメールボックスに加えられる新しいメッセージをもたらします。
In both the above cases, synchronization is required between the re- pository and every client that has not previously noted a change. To keep track of which clients have noticed a global mail state change and changed their local states accordingly, each mailbox has associ- ated with it a list of active clients. Each client has a (potential- ly empty) "update list" of messages which have changed since that client last read them.
両方の上の場合では、同期が再positoryと変化について上述していないすべてのクライアントの間で必要です。 どのクライアントが、それでグローバルな郵便配達人が、変化してください。そうすれば、変えて、彼らのローカルが、各メールボックスにはassoci- atedがあるとそれに従って、述べると述べるのに気付いたかに関する道が活発なクライアントのリストであることを保つために。 各クライアントには、そのクライアントが最後にそれらを読んで以来変化しているメッセージの(潜在的ly空)の「アップデートリスト」があります。
When a client connects to the repository, it executes a DMSP "get- changed-descriptors" operation. This causes the repository to return a list of all descriptor objects on that client's update list As the client receives the changed descriptors, it can store them locally, thus updating the local mail state. After a changed descriptor has been recorded, the client uses the DMSP "reset-descriptors" operation to remove the message from its update list. That descriptor will now not be sent to the client unless (1) it is explicitly requested, or (2) it changes again.
クライアントが倉庫に接続するとき、それは「変えられた記述子であるのに得てください」というDMSP操作を実行します。 倉庫はそれでこれですべての記述子物のリストを返します。クライアントのクライアントのアップデートリストAsは変えられた記述子を受け取ります、それが局所的にそれらを格納できて、その結果、地方のメール状態をアップデートします。 変えられた記述子が記録された後に、クライアントは、アップデートリストからメッセージを取り除くのにDMSP「リセット記述子」操作を使用します。 (1) それが明らかに要求されているか、または(2) 再び変化しない場合、その記述子は現在、クライアントに送られないでしょう。
In this manner, a client can run through its user's mailboxes, get- ting all changed descriptors, incorporating them into the local mail state, and marking the change as recorded.
クライアントはユーザのメールボックスを通してこの様に記録されるとして地方のメール状態にそれらを組み入れるすべての変えられた記述子をチリンチリンに手に入れて、変化をマークに手に入れるように述べることができます。
5.3. Batch operation versus interactive operation
5.3. バッチ運転対対話的な操作
Because of the portable nature of some workstations, they may not al- ways be connected to a network (and able to communicate with the re- pository). Since each client maintains a local mail state, Pcmail users can manipulate the local state while not connected to the repo- sitory. This is known as "batch" operation, since all changes are
いくつかのワークステーションの携帯用の自然それら、アル道は、ネットワークに関連するのとまたは(再positoryとコミュニケートできます。)でありませんように。 各クライアントが地方のメール状態を維持するので、Pcmailユーザはrepo- sitoryに接続されていない間、地方の状態を操ることができます。 すべての変化が知られているので、これは「バッチ」操作として知られています。
Clark & Lambert [Page 14] RFC 993 December 1986
クラークとランバート[14ページ]RFC993 1986年12月
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.
次のクライアントが倉庫に接続すると、クライアントによって記録されて、倉庫の一括しているグローバルな状態に作られます。 クライアントがいつも倉庫に接続されるとき、対話的な操作は起こります。 また、会話型では、すぐに、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 repo- sitory changes its global mail state accordingly. When all changes have been processed, the client begins synchronization, to incor- porate newly-arrived mail, as well as mail state changes by other clients, into the local state.
バッチ・モードで、クライアントと倉庫との相互作用は以下の形を取ります: クライアントは、倉庫に接続して、ユーザによって行われたすべての変更を地方のメール状態に移動します。 repo- sitoryはそれに従って、グローバルなメール状態を変えます。 すべての変化を処理してあるとき、クライアントは同期を始めます、incor- porateの新来のメールに、他のクライアントによるメール州の変化と同様に、地方の状態に。
In interactive mode, since local changes are immediately propagated to the repository, the first part of batch-type operation is elim- inated. The synchronization process also changes; although one syn- chronization 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.
会話型では、地域変化がすぐに倉庫に伝播されるので、バッチ型操作の最初の部分はelim- inatedです。 また、同期の過程は変化します。 クライアントが最初に倉庫に接続を開くと、1syn- chronizationが必要ですが、クライアントは時々、ユーザの要求か自動的のどちらかにその後の連動を実行できます。
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 pic- ture of their mail state without having all their messages present.
より小さいワークステーションは少ししかディスク格納の方法で持っていないかもしれません。 これらのワークステーションで動いているクライアントは完全な地方のコピーのユーザのグローバルなメール状態に十分な余地を決して持っていないかもしれません。 これは、ユーザのものがPcmailのクライアント構造でそれらのすべてのメッセージプレゼントを持っているというわけではなくてそれらのメール状態の明確な映画tureを入手できなければならないことを意味します。
Descriptors provide message information without taking up large amounts of storage. Each descriptor contains a summary of informa- tion on a message. This information includes the message UID, its length in bytes and lines, its status (encoded in the eight system- defined and eight user-defined flags), and portions of its RFC-822 header (the "to:", "from:", "subject:" and "date:" fields). All of this information can be encoded in a small (around 100 bytes) data structure whose length is independent of the size of the message it describes.
大容量ストレージを取らないで、記述子はメッセージ情報を提供します。 各記述子はメッセージにinforma- tionの概要を含んでいます。 この情報がRFC-822ヘッダーのメッセージUID、バイトで表現される長さ、系列、状態(システムが定義した8と8では、ユーザによって定義された旗をコード化する)、および一部を含んでいる、(「以下からの」「以下のこと」、「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 com- plete 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-text operation.
ほとんどのクライアントは問題でほとんどメッセージ記述子に関する全リストを保存できないべきです。 これで、ユーザは彼のすべてのメッセージを持っていることのない彼のメール状態のcom- plete画像を局所的に存在させることができます。 また、クライアントに非常に限られた量のディスクストレージがあるなら、倉庫から記述子の部分集合を得るのも可能です。 短いメッセージが記述子に伴うクライアントの上にあることができて、特に、長いメッセージをDMSP印刷メッセージ操作で印刷するか、またはフェッチメッセージ・テキスト操作で引くことができます。
Clark & Lambert [Page 15] RFC 993 December 1986
クラークとランバート[15ページ]RFC993 1986年12月
6. Typical interactive-style client-repository interaction
6. 典型的な対話的なスタイルクライアント倉庫相互作用
The following example describes a typical communication session between the repository and a client. The client is one of three be- longing to user "Fred". Its name is "office-client", and since Fred uses the client regularly to access his mail, the client is marked as "active". Fred has two mailboxes: "main" is where all of his current mail is stored; "archive" is where messages of lasting importance are kept. The example will run through a simple synchronization opera- tion followed by a series of typical mail state manipulations. Typi- cally, the synchronization will be performed by an application pro- gram that connects to the repository, logs in, synchronizes, and logs out.
以下の例は倉庫とクライアントとの典型的なコミュニケーションセッションについて説明します。 クライアントが3の1つである、ユーザ「フレッド」には切望がありますか? 名前は「オフィスクライアント」です、そして、フレッドが彼のメールにアクセスするのに定期的にクライアントを使用するので、クライアントは「アクティブである」としてマークされます。 フレッドは2個のメールボックスを持っています: 「メイン」は彼の現在のメールのすべてが保存されるところです。 「アーカイブ」は永久に重要なメッセージが保たれるところです。 例は一連の典型的なメール州の操作でtionが続いた簡単な同期オペラを貫くでしょう。 Typi警察署、同期は倉庫に接続して、ログインして、連動して、ログアウトするアプリケーション親グラム実行されるでしょう。
For the example, all DMSP operations will be shown in a user-readable format. In reality, the operations would be sent as a stream of USP blocks consisting of a block-type number followed by a stream of bytes representing the block's components.
例に関しては、すべてのDMSP操作がユーザ読み込み可能な形式で示されるでしょう。 ゴシック体番号から成るUSPブロックの小川がブロックのコンポーネントを表すバイトのストリームで続いたので、ほんとうは、操作を送るでしょう。
In order to access his global mail state, the client software must authenticate Fred to the repository; this is done via the DMSP login operation:
彼のグローバルなメール状態にアクセスするために、クライアントソフトウェアは倉庫にフレッドを認証しなければなりません。 DMSPログイン操作でこれをします:
login ["fred", "fred-password", "office-client", F, F]
ログイン["fred"、「fred-パスワード」、「オフィスクライアント」、F、F]
This tells the repository that Fred is logging in via "office- client", and that "office-client" is identified by an existing client object attached to Fred's user object. The first component of the login block is Fred's repository user name. The second component is Fred's password. The third component is the name of the client com- municating with the repository. The fourth component tells the repo- sitory not to create "office-client" even if it cannot find its client object. The final component tells the repository that Fred's client is not operating in batch mode but rather in interactive mode.
これは、フレッドが「オフィスクライアント」を通してログインしていると倉庫に言います、そして、その「オフィスクライアント」はフレッドのユーザオブジェクトに取り付けられた既存のクライアントオブジェクトによって特定されます。 ログインブロックの最初の部品はフレッドの倉庫ユーザ名です。 2番目のコンポーネントはフレッドのパスワードです。 3番目のコンポーネントは倉庫があるクライアントcom- municatingの名前です。 4番目のコンポーネントは、クライアントオブジェクトを見つけることができないでも「オフィスクライアント」を作成しないようにrepo- sitoryに言います。 最終的なコンポーネントは、フレッドのクライアントがバッチ・モード、しかし、むしろ会話型で働いていないと倉庫に言います。
Fred's authentication checks out, so the repository logs him in, ack- nowledging the login request with an OK block.
フレッドの認証がチェックアウトされるので、倉庫は彼にログインして、OKブロックでack- nowledgingはログイン要求です。
Now that Fred is logged in, the client performs an initial synchroni- zation. This process starts with the client's asking for an up-to- date list of mailboxes:
フレッドがログインされるので、クライアントは初期のsynchroni- zationを実行します。 このプロセスは、クライアントが上から日付へのメールボックスのリストを求め始めます:
list-mailboxes []
リストメールボックス[]
The repository replies with:
以下がある倉庫回答
mailbox-list [["main", 10, 1, 253],
["archive", 100, 0, 101]]
メールボックスリスト[「主である」、10、1、253] [「アーカイブ」、100、0、101]
This tells the client that there are two mailboxes, "main" and "ar- chive". "Main" has 10 messages, one of which is unseen. The next
これは、2個のメールボックス、「メイン」、および「arエゾネギ」があるとクライアントに言います。 「メイン」には、10のメッセージがあります。その1つは見えないです。 次
Clark & Lambert [Page 16] RFC 993 December 1986
クラークとランバート[16ページ]RFC993 1986年12月
incoming message will be assigned a UID of 253. "Archive", on the other hand, has 100 message, none of which are unseen. The next mes- sage sent to "archive" will be assigned the UID 101. There are no new mailboxes in the list (if there were, the client program would create them. On the other hand, if some mailboxes in the client's local list were not in the repository's list, the program would as- sume them deleted by another client and delete them locally as well).
253のUIDは入力メッセージに割り当てられるでしょう。 他方では、「アーカイブ」には、100メッセージがあります。そのいずれも見えなくはありません。 UID101は「アーカイブ」に送られた次期mes賢人に割り当てられるでしょう。 リストにはどんな新しいメールボックスもありません。(あれば、クライアントプログラムはそれらを作成するでしょうに。 他方では、クライアントのローカルのリストのいくつかのメールボックスが倉庫のリストにないなら、プログラムがある、-、別のクライアントによって削除されて、それらをsumeして、局所的にまた、それらを削除します。).
To synchronize the client need only look at each mailbox's contents to see if (1) any new mail has arrived, or (2) if Fred changed any messages on one of his other two clients subsequent to "office- client"'s last connection to the repository.
(1) 何か新しいメールが到着したなら、クライアントを連動させるのは見るためには各メールボックスのコンテンツを見るだけでよいですか、フレッドが何か彼の「オフィスクライアント」における、その後の他の2人のクライアントのひとりに関するメッセージを変えたなら、(2)は倉庫への最後の接続です。
The client asks for any changed descriptors via the "get-changed- descriptors" operation. It requests at most ten changed descriptors since storage is very limited on "office-client".
を通してクライアントがどんな変えられた記述子も求める、「変えられた記述子を得る、」 操作。 それは、ストレージが「オフィスクライアント」で非常に限られているので10が記述子を変えたよう高々要求します。
get-changed-descriptors ["main", 10]
変えられた記述子を得てください。[「メイン」、10]
The repository responds with:
倉庫は以下で応じます。
descriptor-list [[descriptor[
6,
[T T F F F F F F F F F F
F F F F],
"Fred@borax",
"Joe@fab",
"Wed, 23 Jan 86 11:11 EST",
"tomorrow's meeting",
621,
10]]
[descriptor[
10,
[F T F F F F F F F F F F
F F F F],
"Fred",
"Freds-secretary",
"Fri, 25 Jan 86 11:11 EST",
"Monthly progress report",
13211,
350]]
]
記述子リスト[記述子、[6、[T T F F F F F F F F F F F F F F] 621、" Fred@borax "、" Joe@fab "、「水曜日、1986年1月23日の東部標準時11時11分」が「明日は間に合う」10]、[記述子、[10、[F T F F F F F F F F F F F F F F]、「フレッド」、「Freds-秘書」、「金曜日、1986年1月25日の東部標準時11時11分」、「毎月の経過報告書」、13211、350]
The first descriptor in the list is one which Fred deleted on another client yesterday. "Office-client" marks the local version of the message as deleted. The second descriptor in the list is a new one. "Office-client" adds the descriptor to its local list. Since both changes have now been recorded locally, the descriptors can be reset:
リストにおける最初の記述子はフレッドが昨日別のクライアントで削除したものです。 「オフィスクライアント」は削除されるようにメッセージのローカルのバージョンをマークします。 リストにおける2番目の記述子は新しいものです。 「オフィスクライアント」はローカルのリストに記述子を追加します。 両方の変化が現在局所的に記録されて以来、記述子をリセットできます:
reset-descriptors ["main", 6, 10]
リセット記述子[「メイン」、6、10]
Clark & Lambert [Page 17] RFC 993 December 1986
クラークとランバート[17ページ]RFC993 1986年12月
The repository removes from "office-client"'s update list all mes- sages with UIDs between 6 and 10 (in this case just two messages) "Main" has now been synchronized. The client now turns to Fred's "archive" mailbox and asks for the first ten changed descriptors.
倉庫が取り外される、「オフィスクライアント」から、UIDs6〜10(この場合ちょうど2つのメッセージ)「メイン」をもっているすべてのmes賢人が現在持っているアップデートリストは同期しましたか? クライアントは、今、フレッドの「アーカイブ」メールボックスに変わって、最初の10の変えられた記述子を求めます。
get-changed-descriptors ["archive", 10]
変えられた記述子を得てください。[「アーカイブ」、10]
The repository responds with
倉庫は応じます。
descriptor-list []
記述子リスト[]
The zero-length list tells "office-client" that no descriptors have been changed in "archive" since its last synchronization. No new synchronization needs to be performed.
ゼロ・レングスリストは、最後の同期以来記述子が全く「アーカイブ」で変えられていないと「オフィスクライアント」に言います。 どんな新しい同期も、実行される必要がありません。
Fred's client 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 client tries anyway:
フレッドのクライアントは現在、新しいメッセージの上で引く準備ができています。 長い間、メッセージは320の系列です。 十分なストレージが新しいメッセージを保持する「オフィスクライアント」にないかもしれません。 クライアントはとにかく試みます:
fetch-message-text ["main", 10]
フェッチメッセージ・テキスト[「メイン」、10]
The repository begins transmitting the message:
倉庫はメッセージを送り始めます:
message ["From: Fred's-secretary",
"To: Fred",
"Subject: Monthly progress report",
"Date: Fri, 25 Jan 86 11:11 EST",
"",
"Dear Fred,",
"Here is this month's progress report",
...
]
メッセージ[、「From: フレッドのもの秘書」「To: フレッド」、「Subject: Monthly経過報告書」、「日付: 金曜日、1986年1月25日の東部標準時11時11分」、「「「親愛なるフレッド」、「ここに、今月の経過報告書がある」…]、」
Halfway through the message transmission, "office-client" runs out of disk space. Because all DMSP operations are defined to be failure- atomic, the portion of the message already transmitted is destroyed locally and the operation fails. "Office-client" informs Fred that the message cannot be pulled over because of a lack of disk space. The synchronization process is now finished and Fred can start read- ing his mail. The new message that was too big to fit on "office- client" will be marked "off line"; Fred can either remote-print it or delete other messages until he has enough space to store the new mes- sage.
途中で、メッセージ送信で、「オフィスクライアント」は椎間腔を使い果たします。 すべてのDMSP操作が失敗原子であるために定義されるので、既に送られたメッセージの部分は局所的に破壊されます、そして、操作は失敗します。 「オフィスクライアント」は、椎間腔の不足のためにメッセージを引くことができないことをフレッドに知らせます。 同期プロセスは現在終わっていました、そして、フレッド缶の始めは彼のメールをingに読み込みました。 「オフィスクライアント」で合うことができないくらい大きかった新しいメッセージは「オフライン」であるとマークされるでしょう。 または、フレッドがリモート印刷であってそうすることができる、それ、彼には新しいmes賢人を保存できるくらいのスペースがあるまで、他のメッセージを削除してください。
Since he is running in interactive mode, changes he makes to any mes- sages will immediately be transmitted into DMSP operations and sent to the repository. Depending on the client implementation, Fred will either have to execute a "synchronize" command periodically or the client will synchronize for him automatically every so often.
彼が会話型へ駆け込んでいるので、すぐに、彼がどんなmes賢人にも行う変更をDMSP操作に伝えて、倉庫に送るでしょう。 クライアント実装によって、フレッドが定期的に「連動」コマンドを実行しなければならない、さもなければ、クライアントは時々、彼のために自動的に連動するでしょう。
Clark & Lambert [Page 18] RFC 993 December 1986
クラークとランバート[18ページ]RFC993 1986年12月
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 VAX-750 connected to the Internet. The clients run on IBM PCs, XTs, and ATs, as well as Sun workstations, Micro- vaxes, and VAX-750s.
以下のセクションは簡潔にユーザの小規模地域社会にサービスを提供する現在のPcmailシステムについて説明します。 Pcmail倉庫はインターネットに接続されたDEC VAX-750でUNIXで実行されます。 クライアントはIBM PC、XTs、ATs、Sunワークステーション、Micro- vaxes、および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, which are queued until the client connects to the repository. At that time, the changes are performed and the local and global states synchronized. The client then disconnects from the repository.
IBMマシンのためのクライアントコードは単にバッチ・モードで作動します。 ユーザは地方の州の変更を行います。(クライアントが倉庫に接続するまで、変更は列に並ばせられます)。 その時、変化は実行されました、そして、地方の、そして、グローバルな州は連動しました。 そして、クライアントは倉庫から切断します。
Users access and modify their local mail state via a user interface program. The program uses windows and a full-screen mode of opera- tion. Users are given a variety of commands to operate on individual messages as well as mailboxes. The interface allows use of any text editor to compose messages, and adds features of its own to make RFC-822-style header composition easier.
ユーザは、ユーザーインタフェースプログラムを通して地元のメール状態にアクセスして、変更します。 プログラムは窓とオペラtionのフルスクリーンモードを使用します。 メールボックスと同様に個々のメッセージを作動させるさまざまなコマンドをユーザに与えます。 インタフェースは、どんなテキストエディタの使用もメッセージを構成するのを許容して、それ自身のものがRFC822スタイルヘッダー構成をより簡単にする特徴を言い足します。
Synchronization and the processing of queued changes is performed by a separate program, which the user runs whenever he wishes. The pro- gram takes any actions queued while operating the user interface, and converts them into DMSP operations. All queued changes are made be- fore any synchronization is performed.
列に並ばせられた変化の同期と処理は別々のプログラムで実行されます。(願っているときはいつも、ユーザはそれを動かします)。 親グラムは、ユーザーインタフェースを操作している間に列に並ばせられたどんな行動も取って、DMSP操作にそれらを変換します。 すべての列に並ばせられた変更が行われる、存在、前面では、どんな同期も実行されます。
The limitation of IBM PC client operation to batch mode was made be- cause of development environment limitations. The user interface could not work with the network code inside it due to program size limitations. Since MS-DOS has no multi-processing facilities, the two programs could not run in tandem either. The only solution was to provide a two-part client, one part of which read the mail and one part of which interacted with the repository.
バッチ・モードへのIBMのPCクライアント操作の制限をした、開発環境制限が原因がありますか? ユーザーインタフェースはプログラムサイズ制限のためそれの中でネットワークコードで働くことができませんでした。 MS-DOSにはマルチプロセッシング施設が全くないので、2つのプログラムは2人乗り自転車に立候補できませんでした。 唯一のソリューションは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 user interface 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 user interface communicates with the repository through a DMSP
ユーザーインタフェースはDMSPを通って倉庫で交信します。
Clark & Lambert [Page 19] RFC 993 December 1986
クラークとランバート[19ページ]RFC993 1986年12月
implementation built into the GNU-EMACS kernel. Changes to the local mail state are immediately made on the repository; the repository is fast enough that there is little noticeable delay in performing the operation over the network.
実装はGNU-Emacsカーネルを組み込みました。 地方のメール状態への変更はすぐに、倉庫の上で行われます。 倉庫はネットワークの上の操作を実行するめぼしい遅れがほとんどないほど速いです。
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 reposi- tory code is designed to allow several clients belonging to a partic- ular user to "concurrently" modify the user's state. A mailbox lock- ing scheme prevents one client from modifying a mailbox while another client is modifying the same mailbox.
倉庫は4.2/4.3BSD UNIXの上でCで実装されます。 DEC VAX-750sとMicrovaxesの上で作業します、他の倉庫はすぐ、IBM RTマシンとSunワークステーションで動くでしょうが。 reposi- toryコードは、partic- ularユーザのものである数人のクライアントが「同時に」ユーザの状態を変更するのを許容するように設計されています。 ingが計画するメールボックス錠は、別のクライアントが同じメールボックスを変更している間、1人のクライアントがメールボックスを変更するのを防ぎます。
8. Conclusions
8. 結論
Pcmail is now used by a small community of people at the MIT Labora- tory for Computer Science. The repository design works well, provid- ing 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 hundred times that many users. Given sufficient disk storage, it should be able to, since communication between different users' clients and the re- pository 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.
Pcmailは現在、コンピュータScienceにMIT Labora- toryで人々の小規模地域社会によって使用されます。 倉庫デザインはうまくいって、provid- ingは数人のユーザのためにメール状態を保存して、維持する効率的な手段です。 最大10人のユーザが接続されているとき、性能はかなり良いです。 倉庫が多くのそのユーザの10倍か100倍の状態を経営するところで効率的になるかどうかがまだ不明です。 十分なディスクストレージを考えて、できます、異なったユーザのクライアントと再positoryとのコミュニケーションが非常に非同期であって、ありそうである傾向があるので、ユーザが他のことをすることで忙しいときに、要するに、起こるのが中間で長い「静かな間隔」で充満するということであるべきです。
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 reposito- ry 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の別の研究グループのメンバーは現在、高い有用性でユーザの非常に大きい共同体をサポートするように設計された倉庫の模写されて、スケーラブルなバージョンに取り組んでいます。 このreposito- ryもDMSPを使用して、首尾よく現在の倉庫実装を使用するクライアントとコミュニケートしました。 したがって、DMSPは、倉庫デザインのいくつかの風味の上で使用可能であるように思えます。
The IBM PC clients are unfortunately very limited in the way of resources, making local mail state manipulation difficult at times. Synchronization is also relatively time consuming due to the low per- formance 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 un- plugged 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のformance。 PCが使用する「バッチ・モード」は、彼らのネットワークから不-ふさがれて離れている時間の大きな割合を費やすそれらのPCに良い傾向があります。 それは、いつもネットワークに接続されるそれらのPCにいくらか不便であり、有効に「会話型」州の操作を利用するかもしれません。
Clark & Lambert [Page 20] RFC 993 December 1986
クラークとランバート[20ページ]RFC993 1986年12月
The UNIX-based clients are far easier to use than their PC counter- parts. Synchronization is much faster, and there is far more func- tionality in the user interface (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が部品を打ち返すよりはるかに使用しやすいです。 同期ははるかに速いです、そして、はるかに多くのfunc- tionalityがユーザーインタフェースにあります(GNU-Emacsの中を走るインタフェースを持っているのははるかにこの点で助けます)。 Pcmailシステムを使用しているそれらの人々の大部分はUNIXベースのクライアントコードを使用します。
APPENDIX
付録
A. DMSP Protocol Specification
A。 DMSPプロトコル仕様
Following are a list of DMSP operations by object type, their block types and arguments, and their expected acknowledgement block types. Each DMSP block has a different number; the first digit of each block type defines the object being manipulated: Operations numbered 5xx are general, operations numbered 6xx are user operations, operations numbered 7xx are client operations, operations numbered 8xx are mail- box operations, operations numbered 9xx are address operations, operations numbered 10xx are bboard operations, and operations num- bered 11xx are message operations.
以下に、オブジェクト・タイプによるDMSP操作のリスト、彼らのゴシック体、議論、および彼らの予想された承認ゴシック体はいます。 それぞれのDMSPブロックには、異なった数があります。 それぞれのゴシック体の最初のケタは操作される物を定義します: 操作の番号付の5xxは一般的です、そして、操作の番号付の6xxはユーザ操作です、そして、操作の番号付の7xxはクライアント操作です、そして、操作の番号付の8xxはメール箱の操作です、そして、操作の番号付の9xxはアドレス操作です、そして、操作の番号付の10xxはbboard操作です、そして、操作num- bered 11xxはメッセージ操作です。
Failure blocks contain two fields, a "code" and a "why". The "code" is an unsigned number placing the error in one of several broad categories (listed below). The "why" is a text string, possibly ex- plaining the error in greater detail.
失敗ブロックは2つの分野、「コード」、および「なぜ」を含んでいるか。 「コード」はいくつかの広いカテゴリ(以下では、記載されている)の1つに誤りを置く符号のない数です。 「なぜ」はテキスト文字列、ことによると詳細によりすばらしい誤りをplainingする元の連れ合いであるか。
Error codes:
エラーコード:
- 1: network error while reading or writing data
- 1: データを読むか、または書いている間のネットワーク誤り
- 2: internal repository error. This can be due to lack
of memory, a fatal bug, lack of disk space, etc.
- 2: 内部の倉庫誤り。 これはメモリの不足、致命的なバグ、椎間腔の不足などのためであることができます。
- 3: requested object already exists. For example, you
tried to create a mailbox that already exists
- 3: 要求された物は既に存在しています。 例えば、あなたは既に存在するメールボックスを作成しようとしました。
- 4: requested object not found. For example, you tried
to delete a message or a mailbox that doesn't exist.
- 4: 物が当たらなかったよう要求しました。 例えば、あなたは存在しないメッセージかメールボックスを削除しようとしました。
- 5: protocol error. Typically DMSP protocol version
skew.
- 5: 誤りについて議定書の中で述べてください。 通常、DMSPはバージョン斜行について議定書の中で述べます。
- 6: block argument error. For example, a "set-message-flag"
operation was attempted on a bboard by someone
other than the bboard's owner.
- 6: 議論誤りを妨げてください。 例えば、「セットメッセージ旗」操作はbboardでbboardの所有者以外のだれかによって試みられました。
- 7: data read error. The repository was unable to read
the mail state information requested.
- 7: データは誤りを読みます。 倉庫は情報が要求したメール状態を読むことができませんでした。
Clark & Lambert [Page 21] RFC 993 December 1986
クラークとランバート[21ページ]RFC993 1986年12月
- 8: data write error. The repository was unable to
write out changed mail state information, perhaps
because the disk was full.
- 8: データは誤りを書きます。 恐らくディスクが完全であったので、倉庫は変えられたメール州の情報を書き上げることができませんでした。
- 9: operating system error: Should be reserved for
things like fork or pipe call errors.
- 9: オペレーティングシステム誤り: フォークやパイプ呼び出し誤りのようなもののために予約されるべきです。
- 10: unexpected or unknown block type received. For
example, you sent a "delete-mailbox" block and received
a "mailbox-list" block in response.
- 10: 予期していなかったか未知のゴシック体は受信しました。 例えば、あなたがaを送った、「応答におけるメールボックスを削除している「メールボックスリスト」」 ブロックであって受信されたブロック。
Blocks marked "=>" flow from client to repository; blocks marked "<="
flow from repository to client. If more than one block can be sent,
the choices are delimited by "or" ("|") characters.
ブロックは、クライアントから倉庫まで「=>」が流れであるとマークしました。 ブロックは、倉庫からクライアントまで「<=」が流れであるとマークしました。 1ブロック以上を送ることができるなら、“or"が選択を区切る、(「|」、)、キャラクタ。
For clarity, each block type is put in a human-understandable form. The block number is followed by an operation name; this name is never transmitted as part of a USP block. Block arguments are identified by name and type, and enclosed in square brackets. "Record" data types are described by a list of "field-name:field-type" pairs con- tained in square brackets. "Choice" data types are described by a list of "tag-name:tag-type" pairs contained in square brackets. USP data types are defined as follows (the definitions are brief; refer to the USP specification for more detailed descriptions):
明快において、各ゴシック体は人間理解できるフォームに入れられます。 操作名は街区番号のあとに続いています。 この名前は1つのUSPブロックの一部として決して伝えられません。 ブロック議論は、名前とタイプによって特定されて、角括弧で同封されます。 「記録的な」データ型は組まやかしが角括弧でtainedした「フィールド名: フィールド・タイプ」のリストによって説明されます。 「特選している」データ型は組が角括弧に含んだ「タグ名: タグタイプ」のリストによって説明されます。 USPデータ型は以下の通り定義されます(定義は簡潔です; より詳細な記述のためのUSP仕様を参照してください):
A.1. Primitive data types
A.1。 基本データ型
string (S): a series of bytes, null-byte padded to even length and preceded by a 16-bit length specifier. Strings are sent in "net- ascii" format (newline sequence is carriage return followed by linefeed, single carriage returns to be followed by a null byte).
ストリング(S): ヌルバイトは、一連のバイト、長さにさえそっと歩いて、16ビットの長さの特許説明書の作成書で先行しました。 「ネットのASCII」形式でストリングを送ります(ニューライン系列はラインフィードがいうことになった復帰です、ヌルバイトがあとに続くただ一つの復帰)。
- cardinal (C): a 16-bit unsigned number.
- 枢機卿(C): 16ビットの符号のない数。
- long-cardinal (LC): a 32-bit unsigned number.
- 長い枢機卿(LC): 32ビットの符号のない数。
- integer (I): a 16-bit signed number.
- 整数(I): 16ビットは数にサインしました。
- long-integer (LI): a 32-bit signed number.
- 長整数型(LI): 32ビットは数にサインしました。
- boolean (B): a 16-bit number with either a 1 or a 0 in the
16th bit.
- 論理演算子(B): 1のどちらかか0つの1が16番目のビットにある16ビットの数。
A.2. Compound data types
A.2。 合成データ型
- sequence (SEQ): A list of data items, all the same type and
preceded by a 16-bit sequence length specifier.
- 系列(SEQ): データ項目のリストであり、すべての同じくらいが、16ビットの系列長さの特許説明書の作成書でタイプして、先行しました。
Clark & Lambert [Page 22] RFC 993 December 1986
クラークとランバート[22ページ]RFC993 1986年12月
- array (AR): A fixed-length list of data items, all the same
type. A particular array's length is fixed by the application.
- アレイ(AR): データ項目、ちょうど同じタイプの固定長リスト。 特定のアレイの長さはアプリケーションで固定されています。
- record (REC): A list of data items of any type. A
particular record's format is fixed by the application.
- 記録してください(REC): どんなタイプのデータ項目のリスト。 特定の記録の形式はアプリケーションで修理されています。
- choice (CH): One of a list of possible data types. The data
type contained in the choice is identified by a 16-bit numeric
tag. The application interprets the data item based on the tag
value.
- 選択(CH): 可能なデータ型のリストの1つ。 選択に含まれたデータ型は16ビットの数値タグによって特定されます。 アプリケーションはタグ値に基づくデータ項目を解釈します。
A.3. DMSP Abstract Data Types
A.3。 DMSP抽象データ型
Following are data types defined and used only by DMSP:
以下に、単にDMSPによって定義されて、使用されたデータ型があります:
- client: a record with the following format:
REC[name:S, status:C] Status is either 1 (active) or 0
(inactive)
- クライアント: 以下の形式がある記録: REC[名前: S、状態: C]状態は、どちらかの1(アクティブな)か0です。(不活発)です。
- mailbox: a record with the following format:
REC[name:S, next-uid:LC, #msgs:C, #new-msgs:C]
- メールボックス: 以下の形式がある記録: REC[#新しいmsgs: 名前: S、次のuid: LC、#msgs: C、C]
- bboard: a record with the following format:
REC[name:S, first-unread-message-UID:LC
number-of-unseen-messages:C highest-UID:LC]
- bboard: 以下の形式がある記録: REC[最初の読まれていないメッセージUID: 見えないメッセージのLC番号: Cの最も高いUID: 名前: S、LC]
- descriptor: a record with the following format:
- 記述子: 以下の形式がある記録:
- REC[UID:LC, flags:SEQ[B], from, to, date, subject:S,
#bytes:LC, #lines:LC]
- REC[旗: UID: LC、SEQ[B]、線: 日付、subject: S、バイト: #LC、#LC、]
- desc-choice: a choice with the following format:
CH[expunged-message-UID:LC, desc:descriptor] Descriptor
tag number is 1. Expunged-message tag number is 0.
- desc-選択: 以下の形式がある選択: CH、[梢消されて、UIDを通信させてください: LC、desc: 記述子] 記述子タグ番号は1です。 梢消されたメッセージタグ番号は0です。
A.4. General operations
A.4。 一般操作
=> 502 (send-version) [version:C]
<= 500 (ok) [] |
501 (failure) [code:C, why:S]
=>502(バージョンを発信させている)[バージョン: C]<は500(OK)[]と等しいです。| 501 (失敗)[なぜ: コード: C、S]
=> 503 (send-message) [message:SEQ[S]]
<= 500 (ok) [] |
501 (failure) [code:C, why:S]
=>、503 (メッセージを発信させている) [以下を通信させてください、SEQ[S]]<は500(OK)[]と等しいです。| 501 (失敗)[なぜ: コード: C、S]
Clark & Lambert [Page 23] RFC 993 December 1986
クラークとランバート[23ページ]RFC993 1986年12月
A.5. User operations
A.5。 ユーザ操作
=> 600 (login) [name:S, password:S, client:S,
create-client-object?:B
batch-mode?:B]
<= 500 (ok) [] |
501 (failure) [code:C, why:S] |
705 (force-client-reset) []
=>600(ログインします)[名前: S、パスワード: S、Sの、そして、クライアント物を作成しているクライアント: (Bバッチ・モード): B]<は500(OK)[]と等しいです。| 501 (失敗)[コード: C、なぜ: S]| 705 (力のクライアントリセット)[]
=> 601 (logout) []
<= 500 (ok) []
=>601(ログアウトする)[]<=500(OK)[]
=> 602 (set-password) [old:S, new:S]
<= 500 (ok) [] |
501 (failure) [code:C, why:S]
=>602(設定パスワードの)[Sの、そして、新しい老人: S]<は500(OK)[]と等しいです。| 501 (失敗)[なぜ: コード: C、S]
A.6. Client operations
A.6。 クライアント操作
=> 701 (list-clients) []
<= 700 (client-list) [client-list:SEQ[client]]
=>701(リストクライアント)[]<=700(顧客リスト)[顧客リスト: SEQ[クライアント]]
=> 702 (create-client) [client:S]
<= 500 (ok) [] |
501 (failure) [code:C, why:S]
=>702(クライアントを創造している)[クライアント: S]<は500(OK)[]と等しいです。| 501 (失敗)[なぜ: コード: C、S]
=> 703 (delete-client) [client:S]
<= 500 (ok) [] |
501 (failure) [code:C, why:S]
=>703(クライアントを削除している)[クライアント: S]<は500(OK)[]と等しいです。| 501 (失敗)[なぜ: コード: C、S]
=> 704 (reset-client) [client:S]
<= 500 (ok) [] |
501 (failure) [code:C, why:S]
=>704(リセットクライアント)[クライアント: S]<は500(OK)[]と等しいです。| 501 (失敗)[なぜ: コード: C、S]
A.7. Mailbox operations
A.7。 メールボックス操作
=> 801 (list-mailboxes) []
<= 800 (mailbox-list) [mailbox-list:SEQ[mailbox]]
=>801(リストメールボックス)[]<=800(メールボックスリスト)[メールボックスリスト: SEQ[メールボックス]]
=> 802 (create-mailbox) [mailbox:S]
<= 500 (ok) [] |
501 (failure) [code:C, why:S]
=>802(メールボックスを作成している)[メールボックス: S]<は500(OK)[]と等しいです。| 501 (失敗)[なぜ: コード: C、S]
=> 803 (delete-mailbox) [mailbox:S]
<= 500 (ok) [] |
501 (failure) [code:C, why:S]
=>803(メールボックスを削除している)[メールボックス: S]<は500(OK)[]と等しいです。| 501 (失敗)[なぜ: コード: C、S]
Clark & Lambert [Page 24] RFC 993 December 1986
クラークとランバート[24ページ]RFC993 1986年12月
=> 804 (reset-mailbox) [mailbox:S]
<= 500 (ok) [] |
501 (failure) [code:C, why:S]
=>804(リセットメールボックス)[メールボックス: S]<は500(OK)[]と等しいです。| 501 (失敗)[なぜ: コード: C、S]
=> 805 (expunge-mailbox) [mailbox:S]
<= 500 (ok) [] |
501 (failure) [code:C, why:S
=>805(メールボックスを梢消している)[メールボックス: S]<は500(OK)[]と等しいです。| 501 (失敗) [コード: C、なぜ:、S
A.8. Address operations
A.8。 アドレス操作
=> 901 (list-addresses) [mailbox:S]
<= 501 (failure) [code:C, why:S] |
900 (address-list) [address-list:SEQ[S]]
=>901(リストアドレス)[メールボックス: S]<=501(失敗)[コード: C、なぜ: S]| 900 (住所録)[住所録: SEQ[S]]
=> 902 (create-address) [mailbox:S, address:S]
<= 500 (ok) [] |
501 (failure) [code:C, why:S]
=>902(アドレスを作成している)[メールボックス: アドレス: S、S]<は500(OK)[]と等しいです。| 501 (失敗)[なぜ: コード: C、S]
=> 903 (delete-address) [mailbox:S, address:S]
<= 500 (ok) [] |
501 (failure) [code:C, why:S]
=>903(アドレスを削除している)[メールボックス: アドレス: S、S]<は500(OK)[]と等しいです。| 501 (失敗)[なぜ: コード: C、S]
A.9. Bboard operations
A.9。 Bboard操作
=> 1001 (list-bboards) []
<= 1000 (bboard-list) [bboard-list:SEQ[bboard]]
501 (failure) [code:C, why:S]
=1000(bboard-リスト)[bboard-リスト: SEQ[bboard]]>1001(リスト-bboards)[]<=501(失敗)[なぜ: コード: C、S]
=> 1002 (create-bboard) [name:S]
<= 500 (ok) [] |
501 (failure) [code:C, why:S]
=>1002(bboardを作成している)[名前: S]<は500(OK)[]と等しいです。| 501 (失敗)[なぜ: コード: C、S]
=> 1003 (delete-bboard) [name:S]
<= 500 (ok) [] |
501 (failure) [code:C, why:S]
=>1003(bboardを削除している)[名前: S]<は500(OK)[]と等しいです。| 501 (失敗)[なぜ: コード: C、S]
=> 1004 (subscribe-bboard) [name:S]
<= 500 (ok) [] |
501 (failure) [code:C, why:S]
=>1004(bboardを申し込んでいる)[名前: S]<は500(OK)[]と等しいです。| 501 (失敗)[なぜ: コード: C、S]
=> 1005 (unsubscribe-bboard) [name:S]
<= 500 (ok) [] |
501 (failure) [code:C, why:S]
=>1005(bboardを外している)[名前: S]<は500(OK)[]と等しいです。| 501 (失敗)[なぜ: コード: C、S]
Clark & Lambert [Page 25] RFC 993 December 1986
クラークとランバート[25ページ]RFC993 1986年12月
=> 1006 (set-bboard-first-unread) [name:S, UID:LC]
<= 500 (ok) [] |
501 (failure) [code:C, why:S]
=>1006、(セット、最初にbboardに読まれていない、)、[名前: S、UID: LC]<は500(OK)[]と等しいです。| 501 (失敗)[なぜ: コード: C、S]
=> 1007 (list-all-bboards) []
<= 1008 (bboard-name-list) [bboard-name-list:SEQ[S]]
501 (failure) [code:C, why:S]
=>1007(リストオールbboards)[]<=1008(bboard-人名簿)、[bboard-人名簿: SEQ[S]]501(失敗)[なぜ: コード: C、S]
A.10. Message operations
A.10。 メッセージ操作
=> 1102 (get-descriptors) [mailbox:S,
low-uid:LC,
high-uid:LC]
<= 501 (failure) [code:C, why:S] |
1100 (desc-list) [desc-list:SEQ[desc-choice]]
=>1102(記述子を得ている)[メールボックス: S、低いuid: LC、高いuid: LC]<=501(失敗)[コード: C、なぜ: S]| 1100(desc-リスト)[desc-リスト: SEQ[desc-選択]]
=> 1103 (get-changed-descriptors) [mailbox:S,
max-to-send:C]
<= 501 (failure) [code:C, why:S] |
1100 (desc-list) [desc-list:SEQ[desc-choice]]
=>1103(変えられた記述子を得てください)[メールボックス: S、送る最大: C]<=501(失敗)[コード: C、なぜ: S]| 1100(desc-リスト)[desc-リスト: SEQ[desc-選択]]
=> 1104 (reset-changed-descriptors) [
mailbox:S,
start-uid:LC,
end-uid:LC]
<= 500 (ok) [] |
501 (failure) [code:C, why:S]
=>1104(リセットは記述子を変えました)[メールボックス: S、始め-uid: LC、終わり-uid: LC]<は500(OK)[]と等しいです。| 501 (失敗)[なぜ: コード: C、S]
=> 1105 (get-message-text) [mailbox:S,
uid:LC]
<= 501 (failure) [code:C, why:S] |
1101 (message) [message:SEQ[S]]
=>1105(メッセージ・テキストを得ている)[メールボックス: S、uid: LC]<=501(失敗)[コード: C、なぜ: S]| 1101(メッセージ)[メッセージ: SEQ[S]]
=> 1106 (print-message) [mailbox:S,
uid:LC,
printer-name:S]
<= 500 (ok) [] |
501 (failure) [code:C, why:S]
=>1106(印刷メッセージ)[メールボックス: S、uid: プリンタ名: LC、S]<は500(OK)[]と等しいです。| 501 (失敗)[なぜ: コード: C、S]
=> 1107 copy-message[source-mailbox:S,
target-mailbox:S,
source-uid:LC]
<= 501 (failure) [code:C, why:S]
<= 501 (failure) [code:C, why:S] |
1100 (desc-list) [desc-list:SEQ[desc-choice]]
=501(失敗)[コード: C、なぜ: S]1107年の>コピーメッセージ[ソースメールボックス: S、目標メールボックス: S、ソース-uid: LC]<=<=501(失敗)[コード: C、なぜ: S]| 1100(desc-リスト)[desc-リスト: SEQ[desc-選択]]
Clark & Lambert [Page 26] RFC 993 December 1986
クラークとランバート[26ページ]RFC993 1986年12月
=> 1108 (set-flag) [mailbox:S,
uid:LC,
flag-number:C,
flag-setting:B]
<= 500 (ok) [] |
501 (failure) [code:C, why:S] 30
=>1108(セット旗)[メールボックス: S、uid: 旗設定: LC、旗番号: C、B]<は500(OK)[]と等しいです。| 501 (失敗)[コード: C、なぜ: S]30
DMSP block types by number
数に従ったDMSPゴシック体
General block types
一般ゴシック体
ok 500
failure 501
send-version 502
send-message 503
バージョンを発信させている間違いない500失敗501 502、メッセージを発信させている503
User operation block types
ユーザ操作ゴシック体
login 600
logout 601
set-password 602
ログイン600がログアウトする、601セットパスワード602
Client operation block types
クライアント操作ゴシック体
client-list 700
list-clients 701
create-client 702
delete-client 703
reset-client 704
force-client-reset 705
クライアントを創造している顧客リスト700の701 702クライアントを削除している703 704力のクライアントリセットリストクライアントリセットクライアント705
Mailbox operation block types
メールボックス操作ゴシック体
mailbox-list 800
list-mailboxes 801
create-mailbox 802
delete-mailbox 803
reset-mailbox 804
expunge-mailbox 805
メールボックスを梢消する状態でメールボックスを作成している800 801 802メールボックスを削除している803リセットメールボックスリストメールボックス804をメールボックスで記載してください、805
Address operation block types
アドレス操作ゴシック体
address-list 900
list-addresses 901
create-address 902
delete-address 903
住所録900がアドレスを作成する状態で901をリストで記述する、902、アドレスを削除している903
Clark & Lambert [Page 27] RFC 993 December 1986
クラークとランバート[27ページ]RFC993 1986年12月
Bboard operation block types
Bboard操作ゴシック体
bboard-list 1000
list-bboards 1001
create-bboard 1002
delete-bboard 1003
subscribe-bboard 1004
unsubscribe-bboard 1005
set-bboard-first-unread 1006
get-n-new-bboard-descriptors 1007
list-all-bboards 1008
bboard-name-list 1009
bboardを外しているbboardを申し込んでいるbboardを削除しているbboardを作成しているbboard-リスト1000リスト-bboards1001の1002の1003の1004の1005、セット、最初にbboardに読まれていない、n新しいbboard記述子を得ている1006の1007リストオールbboards1008bboard-人名簿1009
Message operation block types
メッセージ操作ゴシック体
descriptor-list 1100
message 1101
get-descriptors 1102
get-changed-descriptors 1103
reset-changed-descriptors 1104
get-message-text 1105
print-message 1106
copy-message 1107
set-flag 1108
記述子を得ている1100年の記述子リストメッセージ1101 1102 1107がセット旗を揚げさせる1103年の変えられた記述子を得ているリセットが記述子を変えているメッセージ・テキストを得ている1104の1105印刷メッセージ1106コピーメッセージ1108
Clark & Lambert [Page 28]
クラークとランバート[28ページ]
一覧
スポンサーリンク
