RFC524 日本語訳
0524 Proposed Mail Protocol. J.E. White. June 1973. (Format: TXT=75385 bytes) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group J. White Request for Comments: 524 SRI-ARC NIC: 17140 13 June 1973
コメントを求めるワーキンググループのJ.の白い要求をネットワークでつないでください: 524 様アークNIC: 17140 1973年6月13日
A Proposed Mail Protocol
提案されたメールプロトコル
AUTHOR'S INTENT
作者の意図
This is the document I offered in (15146,) to write. It's a proposed specification for handling mail in the Network -- a Mail Protocol.
これは私が書くと中(15146)に申し出たドキュメントです。 それはNetworkの取り扱いメールのための提案された仕様です--メールプロトコル。
Main handling is currently implemented as two FTP commands, MAIL and MLFL, which permit an FTP user process to deliver a file or string of text to an FTP server process, designating it as mail to be made available to a user, identified by a local name, in its host. The protocol proposed here is much richer than that, both in terms of the functions it supports, and in terms of the flexibility it provides.
2FTPのコマンド、メール、およびMLFL(ユーザにとって利用可能に作られているためにメールとしてそれを指定して、FTPユーザ・プロセスがテキストのファイルかストリングをFTPサーバプロセスに提供するのを可能にする)が地方名で特定したように主な取り扱いは現在実装されます、ホストで。 ここで提案されたプロトコルはそれがサポートする機能、およびそれが提供する柔軟性に関するそれよりはるかに豊かです。
Although one can (I think) and might, implement software on the basis of this document, this REALLY IS a Request for Comments. Comments, questions, position papers are solicited. There are, I'm sure, bugs in the protocol specified here, and I hope that readers will point them out via RFC as they discover them.
このドキュメントに基づいたある缶(私は考える)と力、道具ソフトウェアですが、これは本当にCommentsのためのRequestです。 コメント、質問、方針書は請求されます。 私はいるのを確信しています、とプロトコルのバグがここで指定しました、そして、彼らが彼らを発見するとき読者がRFCを通して彼らを指摘することを願っています。
Various members of the Network community have, during the last few months, pointed out to me specific inadequacies in the existing mail commands and asked me to be conscious of them in designing a new protocol. I've tried to do that. If anyone feels that his concern wasn't properly dealt with here, or that it slipped through the cracks entirely (for which I apologize in advance), I would appreciate it if he would prod me once more.
Network共同体の様々なメンバーは、ここ数カ月、既存のメールコマンドで特定の不適当を私に指摘して、新しいプロトコルを設計する際にそれらを意識しているように私に尋ねました。 私はそれをしようとしました。 だれかが、彼の関心がここで適切に対処されなかったか、またはそれがひびを完全(私があらかじめわびる)に滑り抜けたのを感じるなら、彼がもう一度私をつつけば、感謝致します。
INTRODUCTION
序論
THE MAIL PROTOCOL ENVIRONMENT
メールプロトコル環境
The Mail Protocol (MP) is implemented by Mail user and server
processes, in keeping with the model for previous high-level
protocols. The Mail user and server processes are further
specified to be also FTP user and server processes, respectively.
That is, MP is implemented as a set of commands accessible from
within the FTP command space.
メールプロトコル(MP)はメールユーザとサーバプロセスによって実装されます、前のハイレベルのプロトコルのためにモデルと共に保つ際に。 メールユーザとサーバプロセスはまた、FTPユーザになるようにさらに指定されます、そして、サーバはそれぞれ処理されます。 すなわち、MPは1セットのコマンドとしてFTPコマンドスペースからアクセスしやすい状態で実装されます。
The MP command set is defined to lie conceptually within a
subsystem, invoked from the FTP command space with the command
MAIL <CFLF>.
MPコマンドセットは、概念的にコマンドメール<CFLF>と共にFTPコマンドスペースから呼び出されたサブシステムに属すために定義されます。
White [Page 1] RFC 524 A Proposed Mail Protocol 13 June 1973
白い[1ページ]RFC524は提案されたメールプロトコル1973年6月13日です。
NOTE: Since a command called 'MAIL' already exists within the
FTP command space, the command name 'XMAIL' might substitute
for 'MAIL' while the current mail commands are being phased
out.
以下に注意してください。 'メール'と呼ばれるコマンドがFTPコマンドスペースの中に既に存在しているので、現在のメールコマンドが段階的に廃止されている間、コマンド名'XMAIL'は'メール'のために代理をするかもしれません。
The MP command set may or may not (according to the implementation
of a particular server) be implemented by a process distinct from
that which implements FTP proper.
MPコマンドセットはプロセスでFTP自体を実装するそれと異なった状態で実装されるかもしれません(特定のサーバの実装に従って)。
The following are implications of the 'subsystem' concept, of
which the reader (and implementer) must be aware:
↓これは'サブシステム'概念の含意です:(そこを読者(そして、implementer)は意識しているに違いありません)。
(1) Names of MP commands are known only within the MP
subsystem. MP commands must (and should naturally) be rejected
by the server if the user process presents them outside of the
subsystem.
(1) MPコマンドの名前はMPサブシステムだけの中で知られています。 ユーザ・プロセスがサブシステムの外にそれらを提示するなら、サーバでMPコマンドを拒絶しなければなりません(そして、自然にそうするべきです)。
(2) Exit from the Mail subsystem (to the FTP command space) is
effected with and only with the command EXIT <CRLF>. FTP
commands must be rejected by the server if the user presents
them while inside the subsystem (i.e., before EXIT is issued).
(2) メールサブシステム(FTPコマンドスペースへの)からの出口は>と単にコマンドEXIT<CRLF>で作用します。 ユーザがサブシステムにはいる間、それらを提示するなら(すなわち、EXITが発行される前に)、サーバでFTPコマンドを拒絶しなければなりません。
(3) The same command name may be assigned without ambiguity to
two entirely different commands, provided that one lies within
the FTP command space and the other within MP, the two being
distinguishable by their contexts. MP and FTP therefore do not
compete for command names, and MP command names may be chosen
without regard for the environment in which the subsystem
resides.
(3) 同じコマンド名はあいまいさなしで2つの完全に異なったコマンドに割り当てられるかもしれません、1つがMPの中でFTPコマンドスペースともう片方に属せば、2がそれらの文脈で区別可能であることで。 したがって、MPとFTPはコマンド名を競争しません、そして、MPコマンド名はサブシステムがある環境への尊敬なしで選ばれるかもしれません。
NOTE: It so happens that there are commands DEFINED within MP
which duplicate the functions of FTP commands and bear the same
names. The effective result is that some commands are
explicitly allowed within MP. The reader will understand that
this fact is consistent with the conventions described in 1-3
above, and that no ambiguities result.
以下に注意してください。 MPの中にFTPコマンドの機能をコピーして、同じ名前を示すコマンドDEFINEDが偶然あります。 有効な結果はいくつかのコマンドがMPの中に明らかに許容されているということです。 読者は、この事実が上で1-3で説明されるコンベンションと一致していて、あいまいさが全く結果として生じないのを理解するでしょう。
The subsystem concept (if not the name 'subsystem') is taken from
Mike Padlipsky's Unified User Level Protocol (UULP), which the
author of the present document strongly supports. The fact that
MP is accessed from FTP, rather than both FTP and MP being
accessed independently from a more general executive program, is
simply a concession to the fact that FTP is widely implemented and
UULP isn't. The author hopes that protocol development will, in
the near future, begin to proceed along the lines exemplified by
UULP.
マイクPadlipskyのUnified User Levelプロトコル(UULP)からサブシステム概念(まして、'サブシステム'という名前)を取ります。(現在のドキュメントの作者は強くそれをサポートします)。 MPがFTPからアクセスされるという事実は、より一般的な管理プログラムから独自にアクセスされるFTPとMPの両方よりむしろ単にFTPが広く実装されるという事実への譲歩です、そして、UULPは譲歩ではありません。 作者は、プロトコル開発が近い将来UULPによって例示された台詞に沿って続き始めることを望んでいます。
White [Page 2] RFC 524 A Proposed Mail Protocol 13 June 1973
白い[2ページ]RFC524は提案されたメールプロトコル1973年6月13日です。
MP conforms to FTP in general syntax. In particular, commands and
their responses are strings of NVT characters; command names are
limited to four or fewer, upper- or lower-case, alphameric
characters, and are terminated by the character SP; commands are
generally terminated with the TELNET New Line sequence (CR LF);
command responses contain both numeric (process readable) and text
(human readable) portions. Both reader and implementer are
referred to the FTP protocol document for a detailed description
of such matters; no attempt has been made to duplicate the
discussion in the present document.
MPは一般に、FTPに構文を従わせます。 コマンドと彼らの応答は特に、NVTキャラクタのストリングです。 コマンド名は、4、または、より少ないか、上側の、または、小文字の英数字に制限されて、キャラクタSPによって終えられます。 一般に、コマンドはTELNET New線系列(CR LF)で終えられます。 コマンド応答は両方の数値(読み込み可能な状態で、処理する)とテキスト(人間読み込み可能な)部分を含んでいます。 読者とimplementerの両方はそのような件の詳述のためのFTPプロトコルドキュメントを参照されます。 現在のドキュメントにおける議論をコピーするのを試みを全くしていません。
The FTP protocol document assigns those replies whose second digit
is '6' to RJE functions. In like manner MP appropriates those
reply codes whose second digit is '7' for reporting results
peculiar to its functions. It is, however, the author's position
that FTP, MP, and the RJE protocol are all best implemented as
subsystems under a common UULP executive, in which case a single
subset of the reply space could be used unambiguously by all three
protocols (and any yet to be defined), since every reply would
implicitly be qualified by the name of the subsystem from which it
emanates.
FTPプロトコルドキュメントは2番目のケタがRJE機能への'6'であるそれらの回答を割り当てます。 同様に、MPは機能に独特の報告結果のために、2番目のケタが'7'であるそれらの回答コードを当てます。 しかしながら、サブシステムとして一般的なUULP幹部社員でFTP、MP、およびRJEプロトコルをすべて実装して、最も良いその場合、明白にすべての3つのプロトコル(そして、まだ定義されるべきいずれも)で回答スペースのただ一つの部分集合は使用できたのが、作者の地位です、あらゆる回答がそれが発するサブシステムの名前によってそれとなく資格があるでしょう、したがって。
THE MAIL MODEL
メールモデル
MP defines mail to be text communicated between users (both human
and processes) in less that (but ideally approaching) real time.
The definition excludes so-called console-to-console
communication, where users exchange information at the character
or line level.
MPは、以下のユーザの間で伝えられたテキスト(人間とプロセスの両方)になるようにメールを定義します。その(理想的にアプローチ)リアルタイム。 定義はコンソールからコンソールへのいわゆるコミュニケーションを除きます。そこでは、ユーザがキャラクタか系列レベルで情報交換します。
Pieces of mail are characterized by such attributes as title,
content, author, and recipient. A piece of mail may be a one- or
two-line message sent from one individual to another, a draft of a
document sent by one individual to a design group for review, a
polished, formal document sent from one group to another, a
message sent to a human user by a process (e.g., an RJE server
process might notify a user by Network Mail when his job has
completed), etc. All such forms of communication are mail and are
supported by MP.
メールの断片はタイトル、内容が書くような属性、および受取人によって特徴付けられます。 1つのメールが、1つか1人の個人から別のものに送られた、2系列のメッセージ、レビューのために1人の個人によって設計グループに送られたドキュメント、1つのグループから別のものに送られた、つやが出て、正式なドキュメント、プロセス(例えば、彼の仕事が通知したとき完成されて、プロセスがNetworkメールでユーザに通知するかもしれないRJEサーバ)などで人間のユーザに送られたメッセージの草稿であるかもしれません。 コミュニケーションのそのようなすべてのフォームが、メールであり、MPによってサポートされます。
Pieces of mail can be forwarded from one location to another
1つの位置からもう1つの位置までメールの断片を進めることができます。
Pieces of mail can be replied to.
メールの断片について答えることができます。
The identity of the author of a piece of mail can be verified,
avoiding forgery and misrepresentation.
偽造と誤伝を避けて、1つのメールの作者のアイデンティティについて確かめることができます。
White [Page 3] RFC 524 A Proposed Mail Protocol 13 June 1973
白い[3ページ]RFC524は提案されたメールプロトコル1973年6月13日です。
Pieces of mail can be permanently recorded, assigned a long-term
identifier by which they can be forever be retrieved for
reference, and entered in catalogs. And access to such recorded
mail can be restricted to a specified subset of the user
community.
永久にメールの断片を記録できます、それらがいつまでも参照のために検索し、カタログに入ることができる長期の識別子が割り当てられて。 そして、そのような記録されたメールへのアクセスはユーザーコミュニティの指定された部分集合に制限される場合があります。
Some hosts accept mail whose recipients reside elsewhere in the
Network, and assume responsibility for delivering the mail to them
(worrying about retrying delivery when hosts are down, etc.), and
acknowledging its delivery to the sender.
ホストの中にはNetworkで受取人がほかの場所に住んでいるメールを受け入れて、彼ら(配送を再試行するのにホストがいつ下がっているかを心配しますなど)に郵便を配達して、配送を送付者に承諾するために責任を負う人もいます。
The picture being painted for the reader is one in which processes
cooperate in various ways to flexibly move and manage Network
mail. The author claims (without proof, of course) that the
picture will in the future get yet more complicated, but that the
proposal specified here can be conveniently enlarged to handle
that picture too.
読者のために描かれる画像はプロセスが柔軟にNetworkメールを動かして、管理する様々な方法で協力するものです。 作者は、画像が将来、まだより複雑になりますが、その画像も扱うために便利にここで指定された提案は拡大できると主張します(もちろん証拠なしで)。
ORGANIZATION OF THIS DOCUMENT
このドキュメントの組織
The rest of this document consists of the following components:
このドキュメントの残りは以下のコンポーネントから成ります:
GLOSSARY
用語集
The concepts introduced briefly in the section above are more
formally defined, and their manner of representation in the
protocol specified.
上でセクションで簡潔に紹介された概念は、より正式に定義されました、そして、彼らのプロトコルにおける表現の方法は指定しました。
MP FUNCTIONS
mp機能
The command sequence is defined by which a user process
initiates each of the logical functions (e.g., Distribution,
Recording, Delivery) which can be performed by a Mail server
process.
ユーザ・プロセスがメールサーバプロセスで実行できるそれぞれの論理関数(例えば、Distribution、Recording、Delivery)を開始するコマンド・シーケンスは定義されます。
EXAMPLE
例
An example of the command-response exchange between a user and
server is given.
ユーザとサーバの間のコマンド応答交換に関する例は出されます。
COMMAND SUMMARY
コマンド概要
A summary of MP commands is given.
MPコマンドの概要をします。
COMMAND REPLIES
コマンド回答
Reply code assignments are given and briefly explained.
回答コード課題は、与えられていて、簡潔に説明されます。
White [Page 4] RFC 524 A Proposed Mail Protocol 13 June 1973
白い[4ページ]RFC524は提案されたメールプロトコル1973年6月13日です。
FORMAL SYNTAX
正式な構文
The formal syntax of the command language is specified.
コマンド言語の正式な構文は指定されます。
In all sections but the last (i.e., the formal syntax presentation), verbose keyword forms are employed, in the interests of clarity. These verbose forms have no existence anywhere but in this document; in implementing a Mail user or server process, the terse keyword forms which appear in the formal syntax presentation are to be employed
すべてのセクションにもかかわらず、最終(すなわち、正式な構文プレゼンテーション)では、冗長なキーワードフォームは明快のために使われます。 何処にも存在を全く持っていませんが、これらの冗長なフォームはこのドキュメントでそうします。 メールユーザかサーバプロセスを実装するのにおいて、正式な構文プレゼンテーションに現れる簡潔なキーワードフォームは採用していることです。
GLOSSARY
用語集
Terms are listed here in alphabetical order. Words or phrases which appear in the definitions with initial letters capitalized are themselves formally defined elsewhere in the glossary.
用語はここにアルファベット順にリストアップされています。 大文字が大文字で書かれている状態で定義に現れるワーズか句が用語集のほかの場所で正式に定義されます。
ACCESS LIST (for a piece of Recorded Mail)
アクセスリスト(1つのRecordedメールのための)
That set of individuals with access to a piece of Recorded Mail,
and for each such individual, the type(s) of access granted to
him.
1つのRecordedメールへのアクセス、およびそのような各個人(承諾された彼のアクセスのタイプ)のためのそのセットの個人。
An Access List is represented in the Protocol as a series of
command pairs (juxtaposed in the command stream), each pair
consisting of an ACCESS command followed immediately (and
optionally) by an ACCESSTYPES command. Each pair of commands
corresponds to one individual in the set.
コマンドのシリーズが対にされるとき(コマンドストリームでは、並置されます)、Access Listはプロトコルで表されます、とACCESSコマンドのそれぞれの組の成るのがすぐに(任意に)、ACCESSTYPESコマンドで続きました。 それぞれの組のコマンドはセットにおける1人の個人に文通されます。
ACCESS <individual> <CA>
アクセスの<の個々の><カリフォルニア>。
ACCESSTYPE <accesstypes> <CA>
ACCESSTYPE<accesstypes><カリフォルニア>。
Command arguments identify the Individual to whom access is
granted, and specify the kind(s) of access allowed him.
Either Read Access, Controlling Access, or both may be
granted.
コマンド議論は、アクセスが承諾されるIndividualを特定して、彼に許されたアクセスの種類を指定します。 Read Access、Controlling Access、または両方を与えるかもしれません。
If no Individual is specified, All is implied. In the
absence of an explicit ACCESSTYPES command, one with only
Read Access specified is to be assumed.
Individualが全く指定されないなら、Allは含意されます。 明白なACCESSTYPESコマンドがないとき、Read Accessだけが指定されている1つは想定されることになっています。
In the absence of an explicit Access List, one granting Read
Access to All and Controlling Access to the Author(s) and the
Clerk is to be assumed.
明白なAccess Listが不在のとき、Author(s)とClerkへのAllとControlling AccessにRead Accessを与える1つは想定されることになっています。
White [Page 5] RFC 524 A Proposed Mail Protocol 13 June 1973
白い[5ページ]RFC524は提案されたメールプロトコル1973年6月13日です。
ACKNOWLEDGMENT (for a piece of Mail)
承認(1つのメールのための)
A form of Unrecorded Mail, generated by a Distribution Agent,
whose Recipient is the Monitor for a previous piece of Mail, which
acknowledges Delivery -- successful or otherwise -- to the
Recipient(s) of that first piece of Mail.
Distributionエージェントによって生成されたRecipientが前の1片のメールのためのDeliveryを承認するMonitorであるUnrecordedメールのフォーム--その最初のメールのRecipient(s)に成功しているか、またはそうではありません。
An Acknowledgment bears the Serial Number of the Mail it
acknowledges, as the Reference Serial Number.
AcknowledgmentはそれがReference Serial Numberとして承認するメールのSerial Numberを持っています。
ACKNOWLEDGMENT CONDITION (for Acknowledgments)
承認状態(承認のための)
The attribute of an Acknowledgment which determines the
circumstances under which it will be generated by the Distribution
Agent.
それがDistributionエージェントによって生成される事情を決定するAcknowledgmentの属性。
The following Acknowledgment Conditions are defined:
以下のAcknowledgment Conditionsは定義されます:
ALWAYS
いつも
Acknowledgment is given when all Deliveries are complete,
regardless of whether or not they are all completed
successfully.
彼らが皆、首尾よく完成するかどうかにかかわらずすべてのDeliveriesが完全であるときに、承認を与えます。
FAILURE
失敗
Acknowledgment is given when all Deliveries are complete if
and only if Delivery to one or more Recipient(s) fails.
そして、すべてのDeliveriesが完全であるときに、承認を与える、1Recipient(s)へのDeliveryが失敗する場合にだけ。
NEVER
まさか
An Acknowledgment is never made.
Acknowledgmentは決して作られていません。
An Acknowledgment Condition is represented in the Protocol by the
command:
Acknowledgment Conditionはコマンドによってプロトコルで表されます:
ACKCONDITION <ackcondition> <CA>
ACKCONDITION<ackcondition><カリフォルニア>。
In the absence of an explicit ACKCONDITION command, one with an
argument of FAILURE is to be assumed.
明白なACKCONDITIONコマンドがないとき、FAILUREの議論がある1つは想定されることになっています。
ACKNOWLEDGMENT TYPE (for Acknowledgments and Progress Reports)
承認タイプ(承認と経過報告書のための)
The attribute of an Acknowledgment or Progress Report which
determines the nature of its Content.
Contentの自然を決定するAcknowledgmentかProgress Reportの属性。
White [Page 6] RFC 524 A Proposed Mail Protocol 13 June 1973
白い[6ページ]RFC524は提案されたメールプロトコル1973年6月13日です。
The following Acknowledgment Types are defined:
以下のAcknowledgment Typesは定義されます:
TERSE
簡潔
The Content of a TERSE Acknowledgment or Progress Report is
specified by the Protocol to be an unembellished list of the
Mail's Recipient(s), and the current Delivery Status for
each (except that those Recipient(s) whose Delivery Status
is SUCCESSFUL shall not be included in the list).
TERSE AcknowledgmentかProgress ReportのContentはプロトコルによって指定されて(リストにDelivery StatusがSUCCESSFULであるそれらのRecipient(s)を含んでいないものとするのを除いて)、メールのRecipient(s)の非潤色されたリストと、それぞれのためにDelivery Statusにします現在の。
The Content of a TERSE Acknowledgment is one or more
instances of the following:
TERSE AcknowledgmentのContentは以下の1つ以上のインスタンスです:
<deliverystatus> <individual> <CRLF>
<の<の個々の><CRLF deliverystatus>>。
TERSE Acknowledgments and Progress Reports are intended to
be process-readable.
TERSE AcknowledgmentsとProgress Reportsがプロセス読み込み可能であることを意図します。
VERBOSE
冗長
The Content of a VERBOSE Acknowledgment or Progress Report
is not specified by the Protocol, but might include a list
of those Recipient(s) to whom the Mail could not be
delivered and why, the times at which Delivery was made to
others, etc.
VERBOSE AcknowledgmentかProgress ReportのContentはプロトコルによって指定されませんが、メールを提供できなかったそれらのRecipient(s)となぜに関するリストを含むかもしれないか、Deliveryが他のものなどにされた回
VERBOSE Acknowledgments and Progress Reports are intended to
be human-readable.
VERBOSE AcknowledgmentsとProgress Reportsが人間読み込み可能であることを意図します。
An Acknowledgment Type is represented in the Protocol by the
command:
Acknowledgment Typeはコマンドによってプロトコルで表されます:
ACKTYPE <acktype> <CA>
ACKTYPE<acktype><カリフォルニア>。
In the absence of an explicit ACKTYPE command, one with an
argument of TERSE is to be assumed.
明白なACKTYPEコマンドがないとき、TERSEの議論がある1つは想定されることになっています。
ALL
すべて
Every conceivable Individual.
想像できるあらゆるIndividual。
AUTHOR (of a piece of Mail)
作者(1つのメールの)
An Individual (there may be more than one) given formal
recognition for having authored a piece of Mail.
1つのメールを書いたためのIndividual(1つ以上があるかもしれない)の与えられた正式な認識。
White [Page 7] RFC 524 A Proposed Mail Protocol 13 June 1973
白い[7ページ]RFC524は提案されたメールプロトコル1973年6月13日です。
AUTHOR LIST (for a piece of Mail)
作者リスト(1つのメールのための)
That set of Individuals who are Author(s) of a piece of Mail.
1つのメールのAuthor(s)であるIndividualsのそのセット。
An Author List is represented in the Protocol as an Individual
List of type AUTHOR.
Author ListはタイプAUTHORのIndividual Listとしてプロトコルで表されます。
CATALOG (of Recorded Mail)
カタログ(記録されたメールの)
A named data base containing the Citation for each member of a set
of logically related pieces of Recorded Mail.
1セットの論理的に関連する片のRecordedメールの各メンバーのためのCitationを含む命名されたデータベース。
CATALOG LIST (for a Piece of Recorded Mail)
カタログリスト(1つの記録されたメールのための)
That set of Catalogs which each contain the Citation for a piece
of Recorded Mail
それぞれ1つのRecordedメールのためのCitationを含むCatalogsのそのセット
A Catalog List is represented in the Protocol as a series of
instances (juxtaposed in the command stream) of the following
command. Each instance corresponds to one Catalog in the set.
Catalog Listは以下のコマンドの一連の例(コマンドの流れでは、並置される)としてプロトコルで表されます。 各例はセットにおける1Catalogに対応しています。
CATALOG <catalog> <CA>
カタログ<カタログ><カリフォルニア>。
CITATION (for a piece of Recorded Mail)
引用(1つのRecordedメールのための)
The Static and Dynamic Attributes of a piece of Recorded Mail.
1つのRecordedメールのStaticとDynamic Attributes。
CITATION COMPONENT
引用コンポーネント
Any one of the Static or Dynamic Attributes which comprise a
Citation.
Citationを包括するStaticかDynamic Attributesのいずれも。
CITATION RETRIEVAL (for a piece of Recorded Mail)
引用検索(1つのRecordedメールのための)
The act of retrieving selected Citation Component(s).
検索の行為はCitation Component(s)を選択しました。
CITATION TEMPLATE
引用テンプレート
A specified subset of the Citation Component(s) for a piece of
Recorded Mail.
1つのRecordedメールのためのCitation Component(s)の指定された部分集合。
A Citation Template is represented in the Protocol by the command:
Citation Templateはコマンドによってプロトコルで表されます:
White [Page 8] RFC 524 A Proposed Mail Protocol 13 June 1973
白い[8ページ]RFC524は提案されたメールプロトコル1973年6月13日です。
CITATIONTEMPLATE <citationtemp> <CA>
CITATIONTEMPLATE<citationtemp><カリフォルニア>。
The argument is a list of Citation Component(s). In the absence
of an explicit CITATIONTEMPLATE command (or if the argument is
null), one specifying Content only is to be assumed.
議論はCitation Component(s)のリストです。 明白なCITATIONTEMPLATEコマンド(議論がヌルであるなら)がないとき、1指定Contentだけが想定されることになっています。
CLERK
事務員
That Individual who prepares a piece of Mail for Recording,
Distribution, or Delivery. Conceptually, the Individual with
proof-reading responsibility for the piece of Mail.
Recording、Distribution、またはDeliveryのために1つのメールを準備するそのIndividual。 概念的である、メールの断片へのプルーフ・リーディング責任があるIndividual。
A Clerk is represented in the Protocol as an Individual List of
type CLERK and length 1.
ClerkはタイプCLERKと長さ1のIndividual Listとしてプロトコルで表されます。
COMMENTS (for a piece of Mail)
コメント(1つのメールのための)
An informal, perhaps verbose description of the Content of a piece
of Mail, or any other information the Author(s) wish to have made
accessible to the Recipient(s) of the Mail.
非公式です、恐らく、Author(s)が持ちたがっているメール、またはいかなる他の情報の1片のContentの冗長な記述でも、メールのRecipient(s)はアクセスしやすくなりました。
Comments are represented in the Protocol by the command:
コメントはコマンドによってプロトコルで表されます:
COMMENTS <comments> <CA2>
<が><CA2>について論評するというコメント
In the absence of an explicit COMMENTS command, one with a null
argument is to be assumed.
明白なCOMMENTSコマンドがないとき、空の項がある1つは想定されることになっています。
CONTENT (of a piece of Mail)
内容(1つのメールの)
It's text.
それはテキストです。
Content is represented in the protocol by either of the two
commands below:
内容は以下の2つのコマンドのどちらかによるプロトコルで表されます:
FILE <CA>
ファイル<カリフォルニア>。
The FILE command implies that the Content of the Mail will
be transmitted (immediately) as a file using the FTP data
transfer commands (e.g., BYTE, SOCK, TYPE) currently in
effect. FILE is exactly equivalent in use to an FTP STOR
command (in its use of data transfer commands, in its
establishment of the data connection, etc.), except that no
pathname is required, and the server, rather than depositing
the transmitted file in his file system, disposes of it in a
manner appropriate for Mail.
(すぐに)事実上、FTPデータ転送を使用するファイルが現在(例えば、BYTE、SOCK、TYPE)を命令するようにFILEコマンドは、メールのContentが伝えられるのを含意します。 FILEはまさに使用中でありFTP STORコマンド(データ転送コマンドの使用、データ接続などの設立における)に同等です、パス名が全く必要でなく、サーバがメールに、適切な方法でそれを彼のファイルシステムの伝えられたファイルを預けるよりむしろ処分するのを除いて。
White [Page 9] RFC 524 A Proposed Mail Protocol 13 June 1973
白い[9ページ]RFC524は提案されたメールプロトコル1973年6月13日です。
TEXT <string> <CA2>
テキスト<ストリング><CA2>。
The TEXT command implies that the Content of the Mail
follows on the TELNET connection as a series of lines, each
delimited from the preceding one by CR LF, and terminated
finally by a CA2.
TEXTコマンドは、メールのContentがTELNET接続のときにCR LFによって前のものからそれぞれ区切られて、CA2によって最終的に終えられた一連の線として続くのを含意します。
CONTROLLING ACCESS (to a piece of Recorded Mail)
アクセスを制御します。(1つのRecordedメールへの)
The right of an Individual to modify a Dynamic Attribute of a
piece of Recorded Mail.
Individualが1つのRecordedメールのDynamic Attributeを変更する権利。
Recording Agents permit an Individual to modify a Dynamic
Attribute of a piece of Recorded Mail if and only if he can
properly identify himself as someone having Controlling Access to
that Mail.
そして、録音エージェントが、Individualが1つのRecordedメールのDynamic Attributeを変更することを許可する、彼が、そのメールにControlling Accessを持ちながら自分がだれかであると適切に認識できる場合にだけ。
CREATION DATE (of a piece of Mail)
作成日付(1つのメールの)
The date and time at which the final draft of a piece of Mail is
completed by the Clerk before he releases it to a Delivery,
Distribution, or Recording Agent for further processing. A single
Creation Date is associated with each piece of Mail. In general,
this date is different from the Delivery or Recording Date, since
Mail often must be queued (for another host to come up) within the
Delivery, Distribution, or Recording Agent's host before Delivery
of Recording can occur.
Clerkによって彼がさらなる処理のためにDelivery、Distribution、またはRecordingエージェントにそれをリリースする前に1つのメールの最終的な草稿が終了している日時。 独身のCreation Dateはそれぞれのメールに関連しています。 一般に、この期日はDeliveryかRecording Dateと異なっています、RecordingのDeliveryが起こることができる前にDelivery、Distribution、またはRecordingエージェントのホストの中にしばしばメールを列に並ばせなければならないので(別のホストが来る)。
A Creation Date is represented in the Protocol by the command:
Creation Dateはコマンドによってプロトコルで表されます:
CREATIONDATE <datetime> <CA>
CREATIONDATE<datetime><カリフォルニア>。
CUTOFF INTERVAL (for Distribution of a piece of Mail)
締切りの間隔(1つのメールのDistributionのための)
That period of time, measured from the Distribution Date, after
which the Distribution Agent is to abandon Delivery attempts for
those Recipient(s) to whom Delivery has not yet been effected.
Distributionエージェントが放棄DeliveryへのどれであるかがそれらのRecipient(s)のためにだれにDeliveryを試みたかの後にDistribution Dateから測定されたその期間はまだ作用していません。
A Cutoff Interval is represented in the Protocol by the command:
Cutoff Intervalはコマンドによってプロトコルで表されます:
CUTOFF <interval> <CA>
締切りの<間隔><カリフォルニア>。
In the absence of an explicit CUTOFF command, one specifying an
Interval of 7 days is to be assumed.
明白なCUTOFFコマンド、7日間のIntervalを指定するのがある1つが不在のとき、想定されてください。
White [Page 10] RFC 524 A Proposed Mail Protocol 13 June 1973
白い[10ページ]RFC524は提案されたメールプロトコル1973年6月13日です。
DELIVERY (of a piece of Mail)
配送(1つのメールの)
The act of transmitting a piece of Mail to the host of one of it's
Recipient(s).
それの1つのホストに1つのメールを伝える行為によるRecipient(s)です。
DELIVERY AGENT
新聞販売店
A process which effects Delivery of a piece of Mail. A
Distribution Agent is by nature also a Delivery Agent.
1つのメールのDeliveryに作用する過程。 自然で、また、DistributionエージェントはDeliveryエージェントです。
DELIVERY DATE (of a piece of Mail to one of its Recipient(s))
納品日(Recipient(s))の1つへの1つのメール
The date and time at which a piece of Mail is Delivered by the
Delivery Agent to a Recipient's system. A multitude of Delivery
Dates, one for each Recipient, are associated with each piece of
Mail.
1つのメールがRecipientのシステムへのDeliveryエージェントによるDeliveredである日時。 Delivery Datesの多数、各Recipientあたり1つはそれぞれのメールに関連しています。
DELIVERY STATUS (for a piece of Mail with respect to a Recipient)
配送状態(Recipientに関する1つのメールのための)
A measure of the extent to which a Delivery Agent has been
successful, at a given point in time, in Delivering a piece of
Mail to one of its Recipient(s). A multitude of Delivery Status',
one for each Recipient, are associated with each piece of Mail.
時間(DeliveringのRecipient(s)の1つへのメールの断片)の与えられた時点のDeliveryエージェントが成功している範囲の基準。 'Delivery Statusの多数'、各Recipientあたり1つはそれぞれのメールに関連しています。
The following Delivery Status' are defined:
以下のDelivery Statusは定義されます:
FAILED
失敗されます。
Delivery was rejected by the Recipient's system (e.g., the
connection request was rejected, the Mail server process
doesn't support Delivery, the Recipient was not recognized
by the server).
配送はRecipientのシステムによって拒絶されました(例えば、接続要求は拒絶されて、メールサーバの過程がDeliveryを支持しないで、またRecipientがサーバによって認識されなかったということでした)。
SUCCESSFUL
うまくいく
Delivery was accomplished successfully.
配送は首尾よく実行されました。
TIMED OUT
外では、調節されています。
Either the Recipient's host was disconnected from the Net at
every Delivery attempt, or no Mail server process has ever
responded to the connection attempt. Hope of Delivery has
been abandoned.
RecipientのホストはあらゆるDelivery試みのときにネットから外されたことがあったというわけではありませんか、メールサーバの過程が全く今までに、接続試みに応じたことがありません。 Deliveryのホープは捨てられました。
White [Page 11] RFC 524 A Proposed Mail Protocol 13 June 1973
白い[11ページ]RFC524は提案されたメールプロトコル1973年6月13日です。
WAITING
待ち
Either the Recipient's host has been disconnected from the
Net at every Delivery attempt, or no Mail server process has
yet responded to the connection attempt. Delivery attempts
are continuing periodically.
RecipientのホストがあらゆるDelivery試みのときにネットから外されたか、またはメールサーバの過程は全くまだ接続試みに応じていません。 配送試みは定期的に続いています。
UNATTEMPTED
UNATTEMPTED
No delivery attempt has yet been made.
まだ配送試みを全くしていません。
DELIVERY TYPE (for a Delivery)
配送タイプ(配送のための)
The nature of the piece of Mail being delivered.
送られるメールの片の本質。
The following Delivery Types are defined:
以下のDelivery Typesは定義されます:
FORWARD
転送
A Delivery of type FORWARD represents a piece of Recorded or
Unrecorded Mail which is being Forwarded.
タイプFORWARDのDeliveryは存在ForwardedであるRecordedか1つのUnrecordedメールを表します。
MAIL
メール
A Delivery of type MAIL represents a piece of Recorded or
Unrecorded Mail whose ultimate source is an Individual.
This is the "normal" Delivery type.
タイプメールのDeliveryは究極の源がIndividualであるRecordedか1つのUnrecordedメールを表します。 これは「正常な」Deliveryタイプです。
NEGATIVE ACKNOWLEDGMENT
否定応答
A Delivery of type NEGATIVE ACKNOWLEDGMENT represents a
piece of Unrecorded Mail generated by a Distribution Agent
and acknowledging unsuccessful or partially unsuccessful
Delivery of a previous piece of Mail (identified by
Reference Serial Number) to it's Recipient(s). The
Recipient for this piece of "system" Mail is the Monitor for
the previous piece of Mail.
タイプNEGATIVE ACKNOWLEDGMENTのDeliveryはDistributionエージェントによって発生した1つのUnrecordedメールを表します、そして、前の1片のメール(Reference Serial Numberによって特定される)の失敗の、または、部分的に失敗のDeliveryをそれに承認するのは、Recipient(s)です。 この「システム」メールのためのRecipientはメールの前の断片のためのMonitorです。
POSITIVE ACKNOWLEDGMENT
肯定応答
A Delivery of type POSITIVE ACKNOWLEDGMENT represents a
piece of Unrecorded Mail generated by a Distribution Agent
and acknowledging successful Delivery of a previous piece of
Mail (identified by Reference Serial Number) to it's
Recipient(s). The Recipient for this piece of "system" Mail
is the Monitor for the previous piece of Mail.
タイプPOSITIVE ACKNOWLEDGMENTのDeliveryはDistributionエージェントによって発生した1つのUnrecordedメールを表します、そして、前の1片のメール(Reference Serial Numberによって特定される)のうまくいっているDeliveryをそれに承認するのは、Recipient(s)です。 この「システム」メールのためのRecipientはメールの前の断片のためのMonitorです。
White [Page 12] RFC 524 A Proposed Mail Protocol 13 June 1973
白い[12ページ]RFC524は提案されたメールプロトコル1973年6月13日です。
PROGRESS REPORT
経過報告書
A Delivery of type PROGRESS REPORT represents a piece of
Unrecorded Mail generated by a Distribution Agent and
reporting the Delivery of a previous piece of Mail
(identified by Reference Serial Number) to it's
recipient(s). The Recipient for this piece of "system" Mail
is the Monitor for the previous piece of Mail.
タイプPROGRESS REPORTのDeliveryはDistributionエージェントによって発生した1つのUnrecordedメールを表します、そして、前の1片のメール(Reference Serial Numberによって特定される)のDeliveryをそれに報告するのは、受取人です。 この「システム」メールのためのRecipientはメールの前の断片のためのMonitorです。
REPLY
返信
A Delivery of type REPLY represents a piece of Recorded or
Unrecorded Mail generated in reply (or pertaining) to a
previous piece of Mail (identified by Reference Serial
Number).
タイプREPLYのDeliveryは回答(または、関係)で前の1片のメール(Reference Serial Numberによって特定される)に発生するRecordedか1つのUnrecordedメールを表します。
Delivery Type is represented in the Protocol by the command:
配送Typeはコマンドによってプロトコルで表されます:
DELIVERYTYPE <deliverytype> <CA>
DELIVERYTYPE<deliverytype><カリフォルニア>。
In the absence of an explicit DELIVERYTYPE command, one with
argument of MAIL is to be assumed.
明白なDELIVERYTYPEコマンドがないとき、メールの議論がある1つは想定されることになっています。
DISTRIBUTE DATE (for a piece of Mail)
日付を分配してください。(1つのメールのための)
The date and time at which a piece of Mail is presented to a
Distribution Agent for Distribution.
1つのメールがDistributionのためにDistributionエージェントに提示される日時。
DISTRIBUTION (of a piece of Mail)
分配(1つのメールの)
The act of Delivering a piece of Mail to its Recipient(s).
Distribution can be effected by either the Clerk's Delivery Agent,
or by a Distribution Agent acting on his behalf.
Recipient(s)へのメールのDelivering a片の行為。 ClerkのDeliveryエージェント、または彼の代理に影響しているDistributionエージェントが分配に作用できます。
DISTRIBUTION AGENT
販売代理人
A Mail server process which acts as intermediary in the delivery
process by accepting Mail for Recipient(s) in hosts other than its
own, and then assuming responsibility for Delivering the Mail to
them and returning Acknowledgment to the appointed Monitor.
Recipient(s)のためにそれ自身のもの以外のホストでメールを受け入れて、次に、Deliveringへの責任が彼らと戻っているAcknowledgmentへのメールであると指定しているMonitorに仮定することによって配送過程で仲介の労をとるメールサーバの過程。
DISTRIBUTION LIST
発送先リスト
In the Delivery or Distribution of a piece of Mail, that set of
Individuals who are to receive Delivery of the Mail.
1つのメール、メールのDeliveryを受け取ることになっているIndividualsのそのセットのDeliveryかDistributionで。
White [Page 13] RFC 524 A Proposed Mail Protocol 13 June 1973
白い[13ページ]RFC524は提案されたメールプロトコル1973年6月13日です。
In the Recording of Mail, that set of Individuals who have
received formal and authorized Delivery of a piece of Mail. The
list is kept current by Distribution Agents. Of course, any
Individual with Read Access to the Mail can himself Deliver it
informally to anyone he chooses without that fact's being
reflected in the Distribution list.
メールのRecording、1つのメールの正式で認可されたDeliveryを受けたIndividualsのそのセットで。 リストはDistributionエージェントによって現在に保たれます。 もちろん、メール缶のDeliver自身へのRead AccessとどんなIndividual。その事実がDistributionで反射していなくて、それはだれにも非公式に記載します彼が、選ぶ。
A Distribution List is represented in the Protocol as a series of
command quintuplets (juxtaposed in the command stream), each
quintuplet consisting of a RECIPIENT command, followed immediately
(and optionally) by any or all of the following in the order
given: a GENERALDELIVERY, a GREETING, a SIGNATURE, and a
DISPOSITION command.
一連のコマンド五つ子(コマンドの流れでは、並置されます)(RECIPIENTコマンドから成る各五つ子の一人)がすぐに(任意に)与えられたオーダーにおける以下のいずれかすべてで後をつけたので、Distribution Listはプロトコルで表されます: GENERALDELIVERY、GREETING、SIGNATURE、およびDISPOSITIONは命令します。
Each quintuplet corresponds to one individual in the set.
各五つ子の一人はセットにおける1人の個人に文通します。
RECIPIENT <individual> <CA>
受取人の<の個々の><カリフォルニア>。
GENERALDELIVERY <CA>
GENERALDELIVERY<カリフォルニア>。
This command is appropriate only in the context of the
Delivery function. If the previous RECIPIENT command
illicits the reply:
このコマンドはDelivery機能の文脈だけで適切です。 前のRECIPIENTコマンドが回答をillicitsするなら:
474 Recipient unrecognized: is General Delivery
OK?
474 受取人認識されていません: Delivery司令官はOKですか?
the issuance of the GENERALDELIVERY command constitutes
consent to proceed with General Delivery to that Recipient.
If no such consent is given, the RECIPIENT command stands
rejected. Unsolicited (i.e., unprompted for) GENERAL
DELIVERY commands in the Distribution List are treated by
the server as NOPs.
GENERALDELIVERYコマンドの発行は、そのRecipientへのDelivery司令官を続けるために同意を構成します。 どんなそのような同意も与えないなら、RECIPIENTは、スタンドが拒絶したと命令します。 Distribution Listの求められていない(すなわち、自発的な)GENERAL DELIVERYコマンドはNOPsとしてサーバによって扱われます。
GREETING <greeting> <CA>
挨拶<挨拶><カリフォルニア>。
The GREETING command specifies the Greeting to be seen by
the Recipient.
Recipientによって見られるように、GREETINGコマンドはGreetingを指定します。
If the first quintuplet in the list contains no GREETING
command, one with a null argument is assumed. Thereafter,
in the absence of an explicit GREETING command, one
identical to that for the previous quintuplet is assumed.
リストにおける最初の五つ子の一人がGREETINGコマンドを全く含まないなら、空の項がある1つは想定されます。 その後、明白なGREETINGコマンドがないとき、前の五つ子の一人にとって、それと同じ1つは想定されます。
SIGNATURE <signature> <CA>
署名<署名><カリフォルニア>。
The SIGNATURE command specifies the Signature to be seen by
the Recipient.
Recipientによって見られるように、SIGNATUREコマンドはSignatureを指定します。
White [Page 14] RFC 524 A Proposed Mail Protocol 13 June 1973
白い[14ページ]RFC524は提案されたメールプロトコル1973年6月13日です。
If the first quintuplet in the list contains no SIGNATURE
command, one with a null argument is assumed. Thereafter,
in the absence of an explicit SIGNATURE command, one
identical to that for the previous quintuplet is assumed.
リストにおける最初の五つ子の一人がSIGNATUREコマンドを全く含まないなら、空の項がある1つは想定されます。 その後、明白なSIGNATUREコマンドがないとき、前の五つ子の一人にとって、それと同じ1つは想定されます。
DISPOSITION <disposition> <CA>
気質<気質><カリフォルニア>。
The DISPOSITION command identifies the intent with which the
Mail is Delivered to the Recipient by the Author(s), and may
take any, all, or none of the following as arguments:
DISPOSITIONコマンドは、Author(s)で、意図をメールがDeliveredであるRecipientに特定して、議論として少しもみなさないかもしれません:
RSVP
RSVP
The Author(s) request a Reply from the Recipient.
Author(s)はRecipientからReplyを要求します。
ACTION
動作
The Author(s) expect some action on the part of the
Recipient. If ACTION doesn't appear, then the Mail is
intended for the Recipient's information only.
Author(s)はRecipient側の何らかの動作を予想します。 ACTIONが現れないなら、メールはRecipientの情報だけのために意図します。
INTERRUPT
中断
The Author(s) declare that examination of the Mail by
the Recipient is urgent. In such cases, the
Recipient's Mail server process may, upon Delivery,
choose to interrupt the Recipient if he happens to be
logged in at a terminal.
Author(s)は、Recipientによるメールの試験が緊急であると宣言します。 そのような場合、Deliveryでは、彼が端末でたまたまログインされるなら、Recipientのメールサーバの過程は、Recipientを中断するのを選ぶかもしれません。
No specific action in response to the presence of any of
these arguments is required; the server is free if he likes
to treat DISPOSITION commands as NOPs.
これらの議論のどれかの存在に対応したどんな特定の動作も必要ではありません。 彼が、DISPOSITIONコマンドをNOPsとして扱うのが好きであるなら、サーバは無料です。
The absence of a DISPOSITION command implies one with no
arguments (i.e., for the Recipient's information only, no
Reply required, and not urgent).
DISPOSITIONコマンドの欠如は主張(すなわち、RecipientのReply必要で、緊急でない情報だけのための)なしで1を含意します。
DYNAMIC ATTRIBUTES (of a piece of Recorded Mail)
ダイナミックな属性(1つのRecordedメールの)
Those attributes of a piece of Recorded Mail -- Distribution List,
Access List, and Catalog List -- which, though given initial
values at Recording Time, can always be modified by an Individual
with Controlling Access to the piece of Mail.
1つのRecordedメールのそれらの属性--分配List、Access List、およびCatalog List--Recording Timeで初期の値を与えますが、Controlling AccessとIndividualがいつもメールの断片に変更できる。
FORWARDING (of Mail received for an Individual)
推進(Individualのために受け取られたメールの)
The act of transferring that set of Mail which has been previously
Delivered to but not Read by an Individual, to another Individual.
それを移す行為は以前にそうであるメールをセットしました。IndividualによるReadだけでない、別のIndividualへのDelivered。
White [Page 15] RFC 524 A Proposed Mail Protocol 13 June 1973
白い[15ページ]RFC524は提案されたメールプロトコル1973年6月13日です。
Users who are known at more than one host can cause their unRead
Mailto be gathered in to a central location by performing the
Forwarding function at each such host (both Individuals being, in
this case, instances of the same User). Mail which has been
Forwarded is considered to have been Read at its source.
1人以上のホストで知られているユーザは働くのによる中心の位置への集まっているコネがそれぞれのそのようなホスト(この場合同じUserのインスタンスである両方のIndividuals)でForwarding機能であったなら彼らのunRead Mailtoを引き起こす場合があります。 ForwardedであるメールはソースのReadであったと考えられます。
FORWARDEE
FORWARDEE
That Individual whose Delivered but UnRead Mail is to be
Forwarded.
Deliveredにもかかわらず、UnReadメールがことであるForwardedであるそのIndividual。
A Forwardee is represented in the Protocol as an Individual List
of type FORWARDEE and length 1.
ForwardeeはタイプFORWARDEEと長さ1のIndividual Listとしてプロトコルで表されます。
GENERAL DELIVERY (of a piece of Mail to an unrecognized Recipient)
局留め郵便(認識されていないRecipientへの1つのメールの)
The act on the part of a server of accepting Delivery of a piece
of Mail on behalf of an intended Recipient whose name the server
doesn't recognize. The server retains the Recipient's name, and
makes it and the other information provided by the user process
available to some competent person, who attempts to make sense of
the Recipient's name. If the Recipient is recognized, the Mail is
'hand' delivered to the appropriate Individual.
サーバが名前を認識しない意図しているRecipientを代表して1つのメールのDeliveryを受け入れるサーバ側の行為。 サーバは、Recipientの名前を保有して、それとユーザ・プロセスで提供されたもう片方の情報は有能な人にとって利用可能になります。(その人は、Recipientの名前を理解できるのを試みます)。 Recipientが認識されるなら、メールは'手で'適切なIndividualに提供されます。
General Delivery of a piece of Mail to one of its intended
Recipient(s) is performed only after the server informs the user
process of its intent and receives the user process' consent. If
that consent is not given, or if the server doesn't implement
General Delivery, the server rejects the Delivery attempt for that
Recipient.
サーバが意図のユーザ・プロセスを知らせて、ユーザ・プロセスの同意を受けた後にだけ意図しているRecipient(s)の1つへの1つのメールのDelivery司令官は実行されます。 サーバがDelivery司令官を実装しないならその同意が与えられないなら、サーバはそのRecipientのためにDelivery試みを拒絶します。
Consent for General Delivery is represented in the Protocol by the
command
Delivery司令官のための同意はコマンドによってプロトコルで表されます。
GENERALDELIVERY <CA>
GENERALDELIVERY<カリフォルニア>。
GREETING (for the Delivery of a piece of Mail to a Recipient)
挨拶(Recipientへの1つのメールのDeliveryのための)
A short greeting to a Recipient of a piece of Mail. 'Dear Dave' is
a valid and perhaps typical Greeting.
1つのメールのRecipientとの短い挨拶。 '親愛なるデーヴ'は有効で恐らく典型的なGreetingです。
A Greeting is represented in the Protocol by the command:
Greetingはコマンドによってプロトコルで表されます:
GREETING <greeting> <CA>
挨拶<挨拶><カリフォルニア>。
White [Page 16] RFC 524 A Proposed Mail Protocol 13 June 1973
白い[16ページ]RFC524は提案されたメールプロトコル1973年6月13日です。
ID (for an Individual)
ID(個人のための)
The password which an Individual may have to present to a Mail
server process, to prove his identity.
Individualがメールサーバプロセスに提示して、彼のアイデンティティであると立証しなければならないかもしれないパスワード。
An Id is represented in the Protocol by the command:
Idはコマンドによってプロトコルで表されます:
ID <id> <CA>
ID<イド><カリフォルニア>。
Ids have nothing to do with accounting, and when required by a
server, they're required only to protect that server from forgery
or misrepresentation.
イドは会計と関係ありません、そして、サーバが必要であると、それらは偽造か誤伝からそのサーバを保護するだけでよいです。
INDIVIDUAL
個人
An instance of a User, identified by NIC Ident, or by the
combination of host and Mailbox Name.
NIC Ident、またはホストの組み合わせで特定されたUserとMailbox Nameのインスタンス。
INDIVIDUAL LIST (of type "t" and length "n")
個々のリスト(タイプ「t」と長さ「n」の)
A set of Individuals.
Individualsの1セット。
An Individual List is represented in the Protocol as a series of
"n" command pairs (juxtaposed in the command stream), each pair
consisting of a "t" command, followed immediately by an ID
command. Each pair corresponds to one Individual in the set.
一連の「n」コマンド組(コマンドストリームでは、並置されます)(「t」コマンドから成る各組)がすぐにIDコマンドで後をつけたので、Individual Listはプロトコルで表されます。 各組はセットにおける1Individualに文通しています。
The ID command is given by the Mail user process at the option of
the Mail server process; and whenever the server requires it, he
must prompt for it with an appropriate reply to the preceding "t"
command. If no such prompt is given, the user process is not
obliged to provide the ID command, but may if it chooses, in which
case the server is obliged to treat it as if it had been prompted
for and found correct.
メールサーバプロセスの選択のときにメールユーザ・プロセスでIDコマンドを与えます。 そして、サーバがそれを必要とするときはいつも、彼はそれのために適切な回答で前の「t」にコマンドをうながさなければなりません。 どんなそのようなプロンプトも与えないなら、ユーザ・プロセスは、IDコマンドを提供するのを強いませんが、まるでそれがうながされたかのようにサーバがそれを扱うのがどのケースに強いられるかに選んで、正しいのが見つけられて、強いるかもしれません。
The ID command is a mechanism by which the server can assure
himself that the user process is not acting without proper
authorization from the Individual(s) involved, i.e., a mechanism
by which a server can protect himself against forgery,
misrepresentation, etc.
IDコマンドはサーバがユーザ・プロセスがIndividual(s)からの適切な承認がなければかかわるのに行動しないことであることを自分に知らせることができるメカニズムです、すなわち、サーバが偽造、誤伝などに対して我が身をかばうことができるメカニズム
"t" <individual> <CA>
「t」<の個々の><カリフォルニア>。
ID <id> <CA>
ID<イド><カリフォルニア>。
White [Page 17] RFC 524 A Proposed Mail Protocol 13 June 1973
白い[17ページ]RFC524は提案されたメールプロトコル1973年6月13日です。
メール
A body of text communicated from one set of Individual(s) to
another, in less than (but ideally approaching) real time.
テキストのボディーは(理想的にアプローチするのを除いて)リアルタイムより以下でIndividual(s)の1セットからもう1セットまで交信しました。
MAILBOX NAME
メールボックス名
The name a User employs at a host to send and receive Mail.
Userがメールを送って、受けるのにホストで使う名前。
MONITOR (for a piece of Mail)
モニター(1つのメールのための)
The Individual who is the recipient for Acknowledgments and
Progress Reports.
AcknowledgmentsとProgress Reportsのための受取人であるIndividual。
A Monitor is represented in the Protocol as an Individual List of
type MONITOR and length 1.
MonitorはタイプMONITORと長さ1のIndividual Listとしてプロトコルで表されます。
Monitor defaults to the Clerk if not explicitly specified.
明らかに指定されないなら、Clerkにデフォルトをモニターしてください。
PROGRESS REPORT (for a piece of Mail)
経過報告書(1つのメールのための)
A form of Unrecorded Mail, generated periodically during the
distribution process by a Distribution Agent, whose Recipient is
the Monitor for a previous piece of Mail, and whose Content is a
list of the Recipient(s) and the current Delivery Status for each.
A Progress Report bears the Serial Number of the Mail whose status
it reports, as the Reference Serial Number.
Recipientが前の1片のメールのためのMonitorであり、ContentがRecipient(s)のリストである分配プロセスの間に定期的にDistributionエージェントによって生成されたUnrecordedメールのフォームとそれぞれのための現在のDelivery Status。 Progress ReportはそれがReference Serial Numberとして状態を報告するメールのSerial Numberを持っています。
PROTOCOL
プロトコル
The Mail Protocol (MP).
メールプロトコル(MP)。
READ (a piece of previously-Delivered Mail)
読んでください。(1つの以前に提供されたメール)
The act, on the part of the User, of examining a piece of
Delivered Mail.
User側の1つのDeliveredメールを調べる行為。
READ ACCESS (to a piece of Recorded Mail)
アクセスを読んでください。(1つのRecordedメールへの)
The right of an Individual to retrieve the Content of a piece of
Recorded Mail.
Individualが1つのRecordedメールのContentを検索する権利。
Recording Agents permit an Individual to retrieve the Content of a
piece of Recorded Mail if and only if he can properly identify
himself as someone having Read Access to that Mail. An Individual
can retrieve the Citation (except Content) from the Recording
Agent independently of whether or not he has Read Access to the
Mail.
そして、録音エージェントが、Individualが1つのRecordedメールのContentを検索することを許可する、彼が、そのメールにRead Accessを持ちながら自分がだれかであると適切に認識できる場合にだけ。 Individualは彼がRead Accessを持っているかどうかの如何にかかわらずRecordingエージェントからメールまでCitation(Contentを除いた)を検索できます。
White [Page 18] RFC 524 A Proposed Mail Protocol 13 June 1973
白い[18ページ]RFC524は提案されたメールプロトコル1973年6月13日です。
READ DATE (of a piece of Mail for one of its Recipient(s))
日付を読んでください。(Recipient(s))の1つの1つのメール
The date and time, necessarily following Delivery, at which a
piece of Mail is Read by a Recipient. A multitude of Read Dates,
one for each Recipient, are associated with each piece of Mail.
日時、必ず次のDelivery。(そこでは、1つのメールがRecipientによるReadです)。 Read Datesの多数、各Recipientあたり1つはそれぞれのメールに関連しています。
RECIPIENT (of a piece of Mail)
受取人(1つのメールの)
An Individual who has or is to receive Delivery of a piece of
Mail.
Individual、だれ、1つのメールのDeliveryは持つことになっているか、または受けることになっているか。
RECORDED MAIL
記録されたメール
A piece of Mail whose Citation is available on a long-term
(indefinite) basis from a Recording Agent.
CitationがRecordingエージェントから長期(無期)のベースで利用可能である1つのメール。
RECORDING
録音
The service provided by a Recording Agent.
Recordingエージェントによって提供されたサービス。
RECORDING AGENT
エージェントを記録します。
A Mail server process which accepts Mail, permanently Records its
Citation, and assigns a pathname by which that information can at
any time be retrieved by an Individual with appropriate access.
永久にのメールを受け入れるメールサーバプロセス、Records、適切なアクセサリーがあるIndividualがいつでもその情報を検索できるCitation、および案配aパス名
RECORDING DATE
録音日付
The date and time at which a piece of Mail is presented to a
Recording Agent for Recording. A single Recording Date is
associated with each piece of Recorded Mail.
1つのメールがRecordingのためにRecordingエージェントに提示される日時。 独身のRecording DateはそれぞれのRecordedメールに関連しています。
REFERENCE SERIAL NUMBER (for an Acknowledgment, Progress Report, or
Reply)
参照通し番号(承認、経過報告書、または回答のための)
The Serial Number of the piece of Mail to which an Acknowledgment,
Progress Report, or Reply refers.
Acknowledgment、Progress Report、またはReplyが参照するメールの片のSerial Number。
A Reference Serial Number is represented in the protocol by the
command:
Reference Serial Numberはコマンドによってプロトコルで表されます:
REFERENCESERIAL <serialnumber> <CA>
REFERENCESERIAL<serialnumber><カリフォルニア>。
In the absence of an explicit REFERENCESERIAL command, no Serial
Number is to be assumed.
明白なREFERENCESERIALコマンドがないとき、Serial Numberを全く想定してはいけません。
White [Page 19] RFC 524 A Proposed Mail Protocol 13 June 1973
白い[19ページ]RFC524は提案されたメールプロトコル1973年6月13日です。
REPLY (to a previous piece of Mail)
返信(前の1片のメールへの)
A piece of Recorded or Unrecorded Mail whose Author(s) are
Recipient(s) of a previous piece of Mail, and which replies or
pertains to that same piece of Mail and bears its Serial Number,
as the Reference Serial Number.
Author(s)が前の1片のメールのRecipient(s)であり、返答するか、またはその同じメールに関係して、Reference Serial NumberとしてSerial Numberを持っているRecordedか1つのUnrecordedメール。
REPORT INTERVAL (for a Progress Report)
レポート間隔(経過報告書のための)
The interval between Progress Reports.
Progress Reportsの間隔。
A Report Interval is represented in the Protocol by the command:
Report Intervalはコマンドによってプロトコルで表されます:
REPORTINTERVAL <interval> <CA>
REPORTINTERVAL<間隔><カリフォルニア>。
In the absence of an explicit REPORTINTERVAL command, one with an
argument whose value is effectively infinite is to be assumed
(i.e., no Progress Reports are to be made).
明白なREPORTINTERVALコマンドがないとき、事実上、値が無限である議論がある1つは想定されることになっています(すなわち、Progress Reportsを全く作ってはいけません)。
REQUESTOR
要請者
The Individual on whose behalf a Mail user process connects to and
interacts with a Mail server process.
メールユーザ・プロセスがだれの代理を接続して、メールサーバで相互作用させるかのIndividualは処理します。
A Requestor is represented in the Protocol as an Individual List
of type REQUESTOR and length 1.
RequestorはタイプREQUESTORと長さ1のIndividual Listとしてプロトコルで表されます。
SERIAL NUMBER (for a piece of Mail)
通し番号(1つのメールのための)
A short-term identifier, assigned to a piece of Mail by the Clerk
(or his system), which accompanies Acknowledgments, Progress
Reports, and Replies, and is used to correlate the latter with the
former. The lifetime of a Serial Number is conceptually from its
assignment by the Clerk until the Delivery of the Recipient(s)
Reply(s) to the Author(s) (or until their decision to send no
reply).
Acknowledgments、Progress Reports、およびRepliesに同伴して、前者で後者を関連させるのに使用されるClerk(または、彼のシステム)によって1つのメールに割り当てられた短期的な識別子。 Serial Numberの寿命はRecipient(s)のDeliveryまでのClerkによる課題から、概念的に、Author(s)(または回答を全く送らないという彼らの決定まで)への(s)が返答しているということです。
A serial Number is represented in the Protocol by the command:
連続のNumberはコマンドによってプロトコルで表されます:
SERIAL <serialnumber> <CA>
連続の<serialnumber><カリフォルニア>。
In the absence of an explicit SERIAL command, no Serial Number is
to be assumed.
明白なSERIALコマンドがないとき、Serial Numberを全く想定してはいけません。
SIGNATURE (for the delivery of a piece of Mail to a Recipient)
署名(Recipientへの1つのメールの配送のための)
A human-readable indication of the Author(s) of a piece of Mail.
The string 'Jim and Dick' is a valid Signature.
1つのメールのAuthor(s)の人間読み込み可能なしるし。 ストリング'ジムとディック'は有効なSignatureです。
White [Page 20] RFC 524 A Proposed Mail Protocol 13 June 1973
白い[20ページ]RFC524は提案されたメールプロトコル1973年6月13日です。
A Signature is represented in the Protocol by the command:
Signatureはコマンドによってプロトコルで表されます:
SIGNATURE <signature> <CA>
署名<署名><カリフォルニア>。
STATIC ATTRIBUTES (of a piece of Recorded Mail)
静的な属性(1つのRecordedメールの)
Those attributes of a piece of Recorded Mail -- Content, Title,
Comments, Author(s), Clerk, and Creation Date -- which are forever
fixed at Recording Time, and hence can never be modified.
いつまでもそうである1つのRecordedメール(内容、Title、Comments、Author(s)、Clerk、およびCreation Date)のそれらの属性は、Recording Timeに固定されていて、したがって、変更されているはずがありません。
Static Attributes can be independently specified with commands
described elsewhere, or specified collectively by reference to an
existing piece of Recorded Mail. The command which follows
assigns to the current piece of Mail the Static Attributes of the
piece of Recorded Mail it references, and is exactly equivalent to
an appropriate set of TITLE, COMMENTS, etc. commands.
静的なAttributesをコマンドがほかの場所で説明されている状態で独自に指定するか、または既存の片のRecordedメールの参照でまとめて指定できます。 続くコマンドは、それが参照をつけるRecordedメールの片のStatic Attributesを現在の片のメールに割り当てて、まさにTITLEの適切なセットに同等です、COMMENTS、などコマンド。
LOCATION <fileaddr> <CA>
位置の<fileaddr><カリフォルニア>。
TITLE (of a piece of Mail)
タイトル(1つのメールの)
A concise description of the Content of a piece of Mail.
1つのメールのContentの簡潔な説明。
A Title is represented in the Protocol by the command:
Titleはコマンドによってプロトコルで表されます:
TITLE <title> <CA>
タイトル<タイトル><カリフォルニア>。
In the absence of an explicit TITLE command, one with a null
argument is to be assumed.
明白なTITLEコマンドがないとき、空の項がある1つは想定されることになっています。
UNRECORDED MAIL
UNRECORDEDメール
Mail which is never presented to a Recording Agent for permanent
storage and cataloging, but which is simply Delivered to its
Recipient(s) by a Delivery Agent.
永久記録媒体のためにRecordingエージェントに提示されて、決してカタログに載っていませんが、単にDeliveryエージェントによるRecipient(s)へのDeliveredであるメール。
UPDATE REQUEST (to a Recording Agent for a piece of Recorded Mail)
更新要求(1つのRecordedメールのためのRecordingエージェントへの)
A request made of a Recording Agent to add, replace, or delete an
Individual from the Access or Distribution List for a piece of
Mail; or to add or delete a Catalog from the Catalog List.
1つのメールのためにAccessかDistribution ListからIndividualを加えるか、取り替えるか、または削除するためにRecordingエージェントでされた要求。 または、Catalog ListからCatalogを加えるか、または削除するために。
An Update Request is represented in the Protocol by the command:
Update Requestはコマンドによってプロトコルで表されます:
UPDATETYPE <updatetype> <CA>
UPDATETYPE<updatetype><カリフォルニア>。
followed immediately in the command stream by an Access,
Distribution or Catalog List.
すぐコマンドストリームでは、Access、DistributionまたはCatalog Listによって続かれています。
White [Page 21] RFC 524 A Proposed Mail Protocol 13 June 1973
白い[21ページ]RFC524は提案されたメールプロトコル1973年6月13日です。
USER
ユーザ
A process or human who sends and/or receives Mail.
メールを送る、そして/または、受けるプロセスか人間。
USER VERIFICATION
ユーザ検証
The act of verifying an ID as that of a specified Individual.
指定されたIndividualのものをIDについて確かめる行為。
USER VERIFICATION AGENT
ユーザ検証エージェント
A Mail server process which performs User Verification
User Verificationを実行するメールサーバプロセス
MP FUNCTIONS
mp機能
A MP function is the request by a Mail user process and the subsequent performance by a server, of a major task related to the management of Mail. The following functions are defined:
MP機能は、メールユーザ・プロセスによる要求とメールの管理に関連する主タスクのサーバによるその後の性能です。 以下の機能は定義されます:
RECORDING
DELIVERY
DISTRIBUTION
FORWARDING
CITATION RETRIEVAL
UPDATE CITATION
USER VERIFICATION
配送分配推進引用検索アップデート引用ユーザ検証を記録します。
One might expect that within the Network there would be just a few Recording Agents (who implement the Recording, Citation Retrieval, and Update Citation functions); a few Distribution Agents (who implement the Distribution function); one or two User Verification Agents (who implement the User Verification Function); and many hosts who implement the Delivery and Forwarding functions.
人は、そこのNetworkの中のそれがわずか数人のRecordingエージェント(Recording、Citation Retrieval、およびUpdate Citationに機能を実装する)であると予想するかもしれません。 数人のDistributionエージェント(Distribution機能を実装します)。 1か2人のUser Verificationエージェント(User Verification Functionを実装します)。 そして、DeliveryとForwardingが機能であると実装する多くのホスト。
In general, a host is free to implement any, all, or none of the functions defined by the Protocol; and a host is free to require a login (for purposes of accounting) before permitting a user process access to any of the function(s) it has implemented.
一般に、ホストは自由にプロトコルによって定義された機能のいずれ、すべて、またはどれかを実装することができません。 そして、それが実装した機能のどれかへのユーザ・プロセスアクセスを可能にする前に、ホストは自由に、ログイン(会計の目的のための)を必要とすることができます。
An FTP server process who chooses to not implement MP or a particular MP function simply rejects the command that requests the unimplemented server with the reply:
単にMPか特定のMP機能を実装しないのを選ぶFTPサーバプロセスは回答で非実装しているサーバを要求するコマンドを拒絶します:
400 Function not implemented.
実装されないで、400は機能します。
A server who chooses to require login before allowing access to the MP subsystem or to an MP function, simply rejects the command that requests the charged-for service with the reply:
MPサブシステム、または、MP機能、単に廃棄物へのアクセスに回答で課金しているサービスを要求するコマンドを許容する前にログインを必要とするのを選ぶサーバ:
White [Page 22] RFC 524 A Proposed Mail Protocol 13 June 1973
白い[22ページ]RFC524は提案されたメールプロトコル1973年6月13日です。
332 Login first, please.
332は最初に、ログインしてください。
The functions defined in MP are:
MPで定義された機能は以下の通りです。
RECORDING
録音
The Recording function is invoked with the command:
Recording機能はコマンドで呼び出されます:
RECORD <CA>
<カリフォルニア>を記録してください。
Once this command is given, the user process shall provide the
following (in any order that suits it):
いったんこのコマンドを与えると、ユーザ・プロセスは以下(それに合うどんなオーダーでも)を提供するものとします:
(1) Any Static Attributes desired.
どんなStatic Attributesも望んでいた(1)。
Content and Clerk are required. Defaults for other
Static Attributes (applied by the server if the
appropriate commands don't appear) are as follows:
内容とClerkが必要です。 他のStatic Attributes(サーバで、適切なコマンドが現れないなら、適用される)のためのデフォルトは以下の通りです:
Title or Comments as specified in the glossary.
用語集の指定されるとしてのタイトルかComments。
Author to the Clerk.
事務員に書きます。
Creation Date to the Recording Date.
作成日付から録音日付。
(2) Initial values for any Dynamic Attributes desired.
(2) 望まれていたあらゆるDynamic Attributesのために値に頭文字をつけてください。
Defaults (applied by the server if the appropriate
commands don't appear) are as follows:
デフォルト(サーバで、適切なコマンドが現れないなら、適用される)は以下の通りです:
Distribution and Catalog Lists to null.
ヌルへの分配とCatalog Lists。
Access List as specified in the glossary.
用語集の指定されるとしてのListにアクセスしてください。
The Recording function is terminated with either of the
commands:
Recording機能はコマンドのどちらかで終えられます:
EXIT <CA> or ABORT <CA>
出口<カリフォルニア>かアボート<カリフォルニア>。
EXIT represents normal termination, and causes the server to
perform the Recording function for which parameters have just
been given. ABORT represents abnormal termination and effects
exit from the function with no action having been taken by the
server; the whole command exchange, beginning with RECORD, is
therefore a NOP.
EXITは正常終了を表して、サーバにパラメタがちょうど与えられているRecording機能を実行させます。 ABORTは異常終了を表します、そして、効果は機能からサーバによって取られた行動なしで出ます。 したがって、RECORDと共に始まって、全体のコマンド交換はNOPです。
White [Page 23] RFC 524 A Proposed Mail Protocol 13 June 1973
白い[23ページ]RFC524は提案されたメールプロトコル1973年6月13日です。
DELIVERY
配送
The Delivery function is invoked with the command:
Delivery機能はコマンドで呼び出されます:
DELIVER <CA>
<カリフォルニア>を提供してください。
Once this command is given, the user process shall provide the
following (in any order that suits it):
いったんこのコマンドを与えると、ユーザ・プロセスは以下(それに合うどんなオーダーでも)を提供するものとします:
(1) Any Static Attributes desired.
どんなStatic Attributesも望んでいた(1)。
Content is required. Defaults for other Static
Attributes (applied by the server if the appropriate
commands don't appear) are as follows:
内容が必要です。 他のStatic Attributes(サーバで、適切なコマンドが現れないなら、適用される)のためのデフォルトは以下の通りです:
Title or Comments as specified in the glossary.
用語集の指定されるとしてのタイトルかComments。
Clerk to null
ヌルへの事務員
Author to the Clerk.
事務員に書きます。
Creation Date to the Delivery Date.
作成日付から納品日。
(2) Any Dynamic Attributes desired.
どんなDynamic Attributesも望んでいた(2)。
Distribution List is required. Defaults (applied by the
server if the appropriate commands don't appear) are as
follows:
分配Listが必要です。 デフォルト(サーバで、適切なコマンドが現れないなら、適用される)は以下の通りです:
Catalog List to null
ヌルへのカタログList
Access List as specified in the glossary.
用語集の指定されるとしてのListにアクセスしてください。
Both of these attributes are for the Recipient's
information only when presented in the context of
Delivery, so defaulting them to null simply implies
that the Clerk doesn't desire that they be
communicated to the Recipient.
これらの属性の両方がヌルへのDeliveryの文脈に示されるのでデフォルトとしているそれらであるときにだけ、Recipientの情報が、Clerkが、それらがRecipientに伝えられることを望んでいないのを単に含意するからです。
(3) Any or all of the following optional parameters:
(3) 以下の任意のパラメタのいずれかすべて:
(a) Delivery Type
(a) 配送タイプ
White [Page 24] RFC 524 A Proposed Mail Protocol 13 June 1973
白い[24ページ]RFC524は提案されたメールプロトコル1973年6月13日です。
(b) Acknowledgment Type
(b) 承認タイプ
The specification of this parameter is appropriate if
and only if the Delivery Type is POSITIVE or NEGATIVE
ACKNOWLEDGMENT or PROGRESS REPORT. In this context,
Acknowledgment Type tells the server how to interpret
the Content of the Acknowledgment.
このパラメタの仕様が適切である、Delivery Typeである場合にだけ、POSITIVE、NEGATIVE ACKNOWLEDGMENTまたはPROGRESS REPORTがそうです。 このような関係においては、Acknowledgment TypeはAcknowledgmentについてContentを解釈する方法をサーバに教えます。
(c) Serial Number
(c) 通し番号
The Serial Number assigned to the piece of Mail being
Delivered. This parameter is inappropriate unless the
Delivery type is FORWARD (in which case the Serial
Number is the one preserved from the previous
Delivery), MAIL, or REPLY.
Serial Numberは存在Deliveredをメールの断片に割り当てました。 このパラメタはDeliveryタイプがFORWARD(その場合、Serial Numberは前のDeliveryから保存されたものである)、メール、またはREPLYでないなら不適当です。
(d) Reference Serial Number
(d) 参照通し番号
The Serial Number assigned to the piece of Mail to
which the current piece of Mail is either an
Acknowledgment, Progress Report, or Reply. The
specification of this parameter is therefore
inappropriate if the Delivery Type is MAIL.
現在の片のメールがAcknowledgment、Progress ReportかReplyのどちらかであるメールの断片に割り当てられたSerial Number。 したがって、このパラメタの仕様はDelivery Typeがメールであるなら不適当です。
The Delivery function is terminated with either of the
commands:
Delivery機能はコマンドのどちらかで終えられます:
EXIT <CA> or ABORT <CA>
出口<カリフォルニア>かアボート<カリフォルニア>。
EXIT represents normal termination, and causes the server to
perform the Delivery function for which parameters have just
been given. ABORT represents abnormal termination and effects
exit from the function with no action having been taken by the
server; the whole command exchange, beginning with DELIVER, is
therefore a NOP.
EXITは正常終了を表して、サーバにパラメタがちょうど与えられているDelivery機能を実行させます。 ABORTは異常終了を表します、そして、効果は機能からサーバによって取られた行動なしで出ます。 したがって、DELIVERと共に始まって、全体のコマンド交換はNOPです。
DISTRIBUTION
分配
The Distribution function is invoked with the command:
Distribution機能はコマンドで呼び出されます:
DISTRIBUTE <CA>
<カリフォルニア>を分配してください。
Once this command is given, the user process shall provide the
following (in any order that suits it):
いったんこのコマンドを与えると、ユーザ・プロセスは以下(それに合うどんなオーダーでも)を提供するものとします:
(1) Any Static Attributes desired.
どんなStatic Attributesも望んでいた(1)。
White [Page 25] RFC 524 A Proposed Mail Protocol 13 June 1973
白い[25ページ]RFC524は提案されたメールプロトコル1973年6月13日です。
Content is required. Defaults for other Static
Attributes (applied by the server if the appropriate
commands don't appear) are as follows:
内容が必要です。 他のStatic Attributes(サーバで、適切なコマンドが現れないなら、適用される)のためのデフォルトは以下の通りです:
Title or Comments as specified in the glossary.
用語集の指定されるとしてのタイトルかComments。
Clerk to null
ヌルへの事務員
Author to the Clerk.
事務員に書きます。
Creation Date to the Delivery Date.
作成日付から納品日。
(2) Any Dynamic Attributes desired.
どんなDynamic Attributesも望んでいた(2)。
Distribution List is required. Defaults (applied by the
server if the appropriate commands don't appear) are as
follows:
分配Listが必要です。 デフォルト(サーバで、適切なコマンドが現れないなら、適用される)は以下の通りです:
Catalog List to null
ヌルへのカタログList
Access List as specified in the glossary.
用語集の指定されるとしてのListにアクセスしてください。
Both of these attributes are for the Recipient(s)
information only when presented in the context of
Distribution, so defaulting them to null simply
implies that the Clerk doesn't desire that they be
communicated to the Recipient(s).
これらの属性の両方がヌルへのDistributionの文脈に示されるのでデフォルトとしているそれらであるときにだけ、Recipient(s)情報が、Clerkが、それらがRecipient(s)に伝えられることを望んでいないのを単に含意するからです。
(3) Any or all of the following optional parameters:
(3) 以下の任意のパラメタのいずれかすべて:
(a) Delivery Type
(a) 配送タイプ
MAIL, FORWARD, or REPLY only.
メール、FORWARD、またはREPLY専用。
(b) Serial Number
(b) 通し番号
The Serial Number of the Mail being Distributed.
The Distribution Agent will relay this Serial
Number to each Recipient at Delivery.
DistributedであるメールのSerial Number。 DistributionエージェントはDeliveryの各RecipientにこのSerial Numberをリレーするでしょう。
(c) Reference Serial Number
(c) 参照通し番号
The Serial Number of the piece of Mail to which the
current piece of Mail is a Reply. The Distribution
Agent will relay this Serial Number to each
Recipient at Delivery. The specification of this
parameter is appropriate if and only if the
Delivery Type is REPLY.
現在の片のメールがReplyであるメールの片のSerial Number。 DistributionエージェントはDeliveryの各RecipientにこのSerial Numberをリレーするでしょう。 このパラメタの仕様が適切である、Delivery Typeである場合にだけ、REPLYはそうです。
White [Page 26] RFC 524 A Proposed Mail Protocol 13 June 1973
白い[26ページ]RFC524は提案されたメールプロトコル1973年6月13日です。
(d) Acknowledgment Condition
(d)承認状態
An Acknowledgment is requested from the
Distribution Agent if and only if the
Acknowledgment Condition is other than NEVER.
AcknowledgmentがDistributionエージェントから要求される、Acknowledgment Conditionが単にそうである、まさか。
(e) Acknowledgment Type
(e) 承認タイプ
(f) Cutoff Interval
(f) 締切りの間隔
(g) Report Interval
(g) レポート間隔
Progress Reports are requested from the
Distribution Agent if and only if this parameter is
specified explicitly.
そして、進歩ReportsがDistributionエージェントから要求される、このパラメタが明らかに指定される場合にだけ。
(h) Monitor
(h)モニター
This parameter is ignored unless either an
Acknowledgment or Progress Reports (or both) are
requested.
AcknowledgmentかProgress Reports(ともに)のどちらかが要求されない場合、このパラメタは無視されます。
The Distribution function is terminated with either of the
commands:
Distribution機能はコマンドのどちらかで終えられます:
EXIT <CA> or ABORT <CA>
出口<カリフォルニア>かアボート<カリフォルニア>。
EXIT represents normal termination, and causes the server to
perform the Distribution function for which parameters have
just been given. ABORT represents abnormal termination and
effects exit from the function with no action having been
taken by the server; the whole command exchange, beginning
with DISTRIBUTE, is therefore a NOP.
EXITは正常終了を表して、サーバにパラメタがちょうど与えられているDistribution機能を実行させます。 ABORTは異常終了を表します、そして、効果は機能からサーバによって取られた行動なしで出ます。 したがって、DISTRIBUTEと共に始まって、全体のコマンド交換はNOPです。
FORWARDING
推進
The Forwarding function is invoked with the command:
Forwarding機能はコマンドで呼び出されます:
FORWARD <CA>
前進の<カリフォルニア>。
Once this command is given, the user process shall provide the
following (in any order that suits it):
いったんこのコマンドを与えると、ユーザ・プロセスは以下(それに合うどんなオーダーでも)を提供するものとします:
(1) Forwardee
(1) Forwardee
White [Page 27] RFC 524 A Proposed Mail Protocol 13 June 1973
白い[27ページ]RFC524は提案されたメールプロトコル1973年6月13日です。
(2) Distribution list
(2) 発送先リスト
This is the set of Individual(s) to whom the Mail is to
be Forwarded.
これはメールがことであるForwardedであるIndividual(s)のセットです。
The Forwarding function is terminated with either of the
commands:
Forwarding機能はコマンドのどちらかで終えられます:
EXIT <CA> or ABORT <CA>
出口<カリフォルニア>かアボート<カリフォルニア>。
EXIT represents normal termination, and causes the server to
perform the Forwarding function for which parameters have just
been given. ABORT represents abnormal termination and effects
exit from the function with no action having been taken by the
server; the whole command exchange, beginning with FORWARD, is
therefore a NOP.
EXITは正常終了を表して、サーバにパラメタがちょうど与えられているForwarding機能を実行させます。 ABORTは異常終了を表します、そして、効果は機能からサーバによって取られた行動なしで出ます。 したがって、FORWARDと共に始まって、全体のコマンド交換はNOPです。
CITATION RETRIEVAL
引用検索
The Citation Retrieval function is invoked with the command:
Citation Retrieval機能はコマンドで呼び出されます:
RETRIEVE <CA>
<カリフォルニア>を検索してください。
Once this command is given, the user process shall provide the
following (in any order that suits it):
いったんこのコマンドを与えると、ユーザ・プロセスは以下(それに合うどんなオーダーでも)を提供するものとします:
(1) The pathname of the piece of Mail whose Citation is to
be retrieved:
(1) Citationが検索されることになっているメールの片のパス名:
PATHNAME <pathname> <CA>
パス名<パス名><カリフォルニア>。
(2) Any or all of the following optional parameters:
(2) 以下の任意のパラメタのいずれかすべて:
(a) Citation Template
(a) 引用テンプレート
(b) Requestor
(b) 要請者
This parameter is required if and only if Content is
requested and Read Access happens not to be granted to
All, in which case the server verifies that the
Requestor has Read Access to the piece of Mail.
そして、このパラメタが必要である、Contentが要求されていて、Read AccessがたまたまAllに与えられない場合にだけ、その場合、サーバは、Requestorがメールの断片にRead Accessを持っていることを確かめます。
(c) FILE <CA>
(c) ファイル<カリフォルニア>。
This command is appropriate if and only if Content is
requested. The presence of this command implies that
the Content of the Mail is to be returned to the user
process (following the return on the TELNET connection
そして、このコマンドが適切である、Contentが要求される場合にだけ。 メールのContentがこのコマンドの存在によってユーザ・プロセスに返されることになっているつもりである、(TELNET接続へのリターンに続くこと。
White [Page 28] RFC 524 A Proposed Mail Protocol 13 June 1973
白い[28ページ]RFC524は提案されたメールプロトコル1973年6月13日です。
of any other Citation Component(s) requested) as a
file using the FTP data transfer commands (e.g., BYTE,
SOCK, TYPE) currently in effect. FILE is exactly
equivalent in effect to an FTP RETR command (in its
use of data transfer commands, in its establishment of
the data connection etc.) except that no pathname is
required.
要求されたいかなる他のCitation Component(s)も) ファイルとして、FTPデータ転送を使用すると、事実上、(例えば、BYTE、SOCK、TYPE)は現在、命令されます。 パス名は全く必要でないのを除いて、FILEがまさにFTP RETRコマンド(データ転送コマンドの使用、データ接続などの設立における)に有効な状態で同等です。
In the absence of a FILE command, Content is returned
on the TELNET connection like any other Citation
Component.
FILEコマンドがないとき、TELNET接続のときにいかなる他のCitation ComponentのようにもContentを返します。
The server returns the Citation Components in the
order requested by the user process (except that
Content, if requested as a file, is always returned
after the 'end of citation' indication), each as a
reply whose numeric code is 172 and whose text is
exactly the command normally used to communicate that
same parameter to the server. A reply whose numeric
code is 173 terminates the reply list.
サーバはユーザ・プロセスで要求されたオーダーでCitation Componentsを返します(ファイルとして要求するなら'引用の終わり'指示の後にいつもContentを返すのを除いて)、数字コードが172であり、テキストがまさにコマンドである回答がそれぞれ通常以前はその同じパラメタをサーバによく伝えていたとき。数字コードが173である回答は回答リストを終えます。
Title and Content, which (in general) may each contain
the TELNET New Line sequence (CR LF), are represented
as continued replies, using the FTP reply continuation
convention (see the FTP protocol document). The first
four characters of each reply line except the first
and last are blanks inserted by the server which must
be deleted by the user process to correctly recover
the value of the Title or Content.
タイトルとContent((一般に)それぞれ、TELNET New線系列(CR LF)を含むかもしれない)は継続的な回答として表されます、FTP回答継続コンベンションを使用して(FTPプロトコルドキュメントを見てください)。 1番目と最終以外のそれぞれの回答系列の最初の4つのキャラクタが、正しくTitleの値を回復するためにユーザ・プロセスで削除しなければならないサーバによって挿入された空白かContentです。
The Citation Retrieval function is terminated with either of
the commands:
Citation Retrieval機能はコマンドのどちらかで終えられます:
EXIT <CA> or ABORT <CA>
出口<カリフォルニア>かアボート<カリフォルニア>。
EXIT represents normal termination, and causes the server to
perform the Citation Retrieval function for which parameters
have just been given. ABORT represents abnormal termination
and effects exit from the function with no action having been
taken by the server; the whole command exchange, beginning with
RETRIEVE, is therefore a NOP.
EXITは正常終了を表して、サーバにパラメタがちょうど与えられているCitation Retrieval機能を実行させます。 ABORTは異常終了を表します、そして、効果は機能からサーバによって取られた行動なしで出ます。 したがって、RETRIEVEと共に始まって、全体のコマンド交換はNOPです。
White [Page 29] RFC 524 A Proposed Mail Protocol 13 June 1973
白い[29ページ]RFC524は提案されたメールプロトコル1973年6月13日です。
UPDATE CITATION
アップデート引用
The Update Citation function is invoked with the command:
Update Citation機能はコマンドで呼び出されます:
UPDATE <CA>
アップデート<カリフォルニア>。
Once this command is given, the user process shall provide the
following (in any order that suits it):
いったんこのコマンドを与えると、ユーザ・プロセスは以下(それに合うどんなオーダーでも)を提供するものとします:
(1) Requestor
(1) 要請者
This parameter is required unless Controlling Access has
been granted to All, in which case it is treated as a NOP
if given. The server verifies that the Requestor has
Controlling Access to the piece of Mail.
Controlling AccessがAllに与えられていない場合、このパラメタが必要です、その場合、考えて、それはNOPとして扱われます。 サーバは、Requestorがメールの断片にControlling Accessを持っていることを確かめます。
(2) One or more Update Requests
(2) 1Update Requests
The Update Citation function is terminated with either of the
commands:
Update Citation機能はコマンドのどちらかで終えられます:
EXIT <CA> or ABORT <CA>
出口<カリフォルニア>かアボート<カリフォルニア>。
EXIT represents normal termination, and causes the server to
perform the Update Citation function for which parameters have
just been given. ABORT represents abnormal termination and
effects exit from the function with no action having been taken
by the server; the whole command exchange, beginning with
UPDATE, is therefore a NOP.
EXITは正常終了を表して、サーバにパラメタがちょうど与えられているUpdate Citation機能を実行させます。 ABORTは異常終了を表します、そして、効果は機能からサーバによって取られた行動なしで出ます。 したがって、UPDATEと共に始まって、全体のコマンド交換はNOPです。
USER VERIFICATION
ユーザ検証
The User Verification function is invoked with the command:
User Verification機能はコマンドで呼び出されます:
VERIFY <CA>
<カリフォルニア>について確かめてください。
Once this command is given, the user process shall specify
any number of Requestors.
いったんこのコマンドを与えると、ユーザ・プロセスはいろいろなRequestorsを指定するものとします。
The server prompts for the Id for each, the user process
provides it, and the server returns a reply whose numeric
code is 272 is the Id is correct or 472 otherwise.
それぞれのためのIdのためのサーバプロンプト、ユーザ・プロセスはそれを提供します。そうでなければ、サーバは数字コードが272がIdが正しいということであるということである1か472の回答を返します。
The User Verification function is terminated with either of the
commands:
User Verification機能はコマンドのどちらかで終えられます:
EXIT <CA> or ABORT <CA>
出口<カリフォルニア>かアボート<カリフォルニア>。
White [Page 30] RFC 524 A Proposed Mail Protocol 13 June 1973
白い[30ページ]RFC524は提案されたメールプロトコル1973年6月13日です。
EXAMPLE
例
In the example below, a short message is recorded for public access, and distributed to a single recipient. The user process is assumed already connected to the server.
以下の例では、短いメッセージは、パブリックアクセスのために記録されて、独身の受取人に分配されます。 ユーザ・プロセスはサーバに関連していると既に思われます。
Note: This would be the implementation of NIC Journal Submission,
where the NIC is understood to be both a Recording and
Distribution Agent.
以下に注意してください。 これはNIC Journal Submissionの実装でしょう。そこでは、NICがRecordingとDistributionエージェントの両方であることが理解されています。
Replies from the server are in brackets.
サーバからの回答が括弧にあります。
MAIL <CA>
メール<カリフォルニア>。
The Mail system is invoked.
[261 RE DE DI FW CI UP UV -- supported.]
メールシステムは呼び出されます。 [261 RE DE DI FW CI UP UV--サポートされます。]
REC <CA>
REC<カリフォルニア>。
The Recording function is invoked.
[200 OK.]
Recording機能は呼び出されます。 [200 OK。]
TITL SMFS Runs on TENEX 1.31 at the NIC <CA>
TITL SMFSはNIC<カリフォルニア>でTENEX1.31の上で作業します。
A Title is given
[200 OK.]
Titleを与えます。[200 OK。]
TEXT The NIC came up on TENEX 1.31 on 1-APR. <CRLF> I tried SMFS
here on the new monitor and it <CRLF> works fine. I don't
understand why I had <CRLF> problems running your copy of the code
at <CRLF> BBN-TENEX. Are you still unable to reference <CRLF> the
same archived file from two different <CRLF> TENEXs? <CA2>
TEXT NICは1 4月にTENEX1.31に近づきました。 <CRLF>Iはここ、新しいモニターとそれでSMFSを試みました。<CRLF>は罰金を扱います。 私は、<CRLF>BBN-TENEXであなたのコードのコピーを動かすことにおける<CRLF>問題がなぜあったかを理解していません。 同じくらいがファイルを格納した参照<CRLF>にあなたが2異なった<CRLF>TENEXs?静めて、ことです。 <CA2>。
The Content of the message is entered.
[200 OK.]
メッセージのContentは入られます。 [200 OK。]
CLER WHITE@SRI-ARC <CR>
CLER WHITE@SRI-ARC 、lt;、CR>。
The Clerk is identified as White at SRI-ARC.
[330 OK. Now Id, please]
ClerkはホワイトとしてSRI-ARCで特定されます。 [330 OK。 Id、現在、お願いします]
ID id <CA>
IDイド<カリフォルニア>。
His Id is supplied.
[200 OK.]
彼のIdを供給します。 [200 OK。]
White [Page 31] RFC 524 A Proposed Mail Protocol 13 June 1973
白い[31ページ]RFC524は提案されたメールプロトコル1973年6月13日です。
EXIT <CA>
出口<カリフォルニア>。
Exit from the Recording function is effected, and the pathname
'15490' is returned by the Recording Agent for the now Recorded
Mail.
[270 15490 -- is assigned as the pathname.]
作用するRecording機能、および'15490が'Recordingエージェントによって返されるパス名から出る、現在のRecordedメール [270 15490--パス名として、割り当てられます。]
DIST <CA>
DIST<カリフォルニア>。
The Distribution function is invoked.
[200 OK.]
Distribution機能は呼び出されます。 [200 OK。]
LOC SRI-ARC 15490 <CA>
LOC様アーク15490<カリフォルニア>。
The message just recorded is specified for Distribution.
[200 OK.]
ただ記録されたメッセージはDistributionに指定されます。 [200 OK。]
RECI * DHC <CA>
RECI*DHC<カリフォルニア>。
The Recipient is specified via NIC Ident to be Dave Crocker at
UCLA-NMC.
[200 OK.]
Recipientは、UCLA-NMCのデーヴ・クロッカーになるようにNIC Identを通して指定されます。 [200 OK。]
GREE Dave <CA>
グレーデーヴ<カリフォルニア>。
A Greeting is given.
[200 OK.]
Greetingを与えます。 [200 OK。]
DISP R
DISP R
A reply is requested.
[200 OK.]
回答は要求されています。 [200 OK。]
SIGN Jim
ジムにサインしてください。
The message is signed.
[200 OK.]
メッセージはサインされます。 [200 OK。]
ACKC A <CA>
ACKCは<カリフォルニア>です。
Acknowledgment of the Mail's Delivery is requested whether
Delivery succeeds or fails..
[200 OK.]
Deliveryが成功するか、または失敗することにかかわらずメールのDeliveryの承認は要求されています。 [200 OK。]
ACKT T <CA>
ACKT T<カリフォルニア>。
The Acknowledgment is to be terse.
[200 OK.]
Acknowledgmentは簡潔であることになっています。 [200 OK。]
White [Page 32] RFC 524 A Proposed Mail Protocol 13 June 1973
白い[32ページ]RFC524は提案されたメールプロトコル1973年6月13日です。
CUT 1 D <CA>
カット1D<カリフォルニア>。
If Delivery hasn't been effected within 24 hours, the attempt
is to be abandoned (and an Acknowledgment of failure returned).
The Monitor (to whom the Acknowledgment is sent) is allowed to
default to the Clerk.
[200 OK.]
Deliveryが24時間以内に作用していないなら、試みは捨てられる(失敗のAcknowledgmentは戻りました)ことです。 Monitor(Acknowledgmentが送られる)はClerkをデフォルトとすることができます。 [200 OK。]
SERI serial <CA>
セリ族の連続の<カリフォルニア>。
A Serial Number is assigned for purposes of coordinating
Acknowledgment and Reply. A desirable implementation of the
sender's user and server processes is one in which the Serial
Number is assigned by the user process, rather than by the
human user himself in such a way that his server process can
automatically make the association between original Mail, and
subsequent Acknowledgment and Reply.
[200 OK.]
Serial NumberはAcknowledgmentとReplyを調整する目的のために割り当てられます。 送付者のユーザとサーバの過程の望ましい実現はSerial Numberが人間のユーザ自身でというよりむしろユーザ・プロセスで彼のサーバの過程が自動的にオリジナルのメールと、その後のAcknowledgmentとReplyとの協会を作ることができるような方法で割り当てられるものです。 [200 OK。]
EXIT <CA>
出口<カリフォルニア>。
Exit from the Distribution function is effected.
[200 OK.]
Distribution機能からの出口は作用しています。 [200 OK。]
EXIT <CA>
出口<カリフォルニア>。
Exit from the Mail subsystem is effected.
[200 OK.]
メールサブシステムからの出口は作用しています。 [200 OK。]
White [Page 33] RFC 524 A Proposed Mail Protocol 13 June 1973
白い[33ページ]RFC524は提案されたメールプロトコル1973年6月13日です。
COMMAND SUMMARY
コマンド概要
Every command requires at least one reply from the server.
あらゆるコマンドがサーバから少なくとも1つの回答を必要とします。
THOSE SPECIFIC TO MP
MPにとって、特定のそれら
ABORT <CA>
ACCESS <individual> <CA>
ACCESSTYPES <accesstypes> <CA>
ACKCONDITION <ackcondition> <CA>
ACKTYPE <acktype> <CA>
AUTHOR <individual> <CA>
CATALOG <catalog> <CA>
CITATIONTEMPLATE <citationtemp> <CA>
CLERK <individual> <CA>
COMMENTS <comments> <CA>
CREATIONDATE <datetime> <CA>
CUTOFF <interval> <CA>
DELIVER <CA>
DELIVERYTYPE <deliverytype> <CA>
DISPOSITION <disposition> <CA>
DISTRIBUTE <CA>
EXIT <CA>
FILE <CA>
FORWARD <CA>
FORWARDEE <individual> <CA>
GENERALDELIVERY <CA>
GREETING <greeting> <CA>
ID <id> <CA>
LOCATION <fileaddr> <CA>
MAIL <CA>
MONITOR <individual> <CA>
PATHNAME <pathname> <CA>
RECIPIENT <individual> <CA>
RECORD <CA>
REFERENCESERIAL <serialnumber> <CA>
REPORTINTERVAL <interval> <CA>
REQUESTOR <individual> <CA>
RETRIEVE <CA>
SERIAL <serialnumber> <CA>
SIGNATURE <signature> <CA>
TEXT <string> <CA2>
TITLE <title> <CA>
UPDATE <CA>
UPDATETYPE <updatetype> <CA>
VERIFY <CA>
個々の<acktype><カリフォルニアの>カリフォルニア>アクセス<><カリフォルニア>ACCESSTYPES<accesstypes><カリフォルニア>ACKCONDITION<ackcondition><カリフォルニア>ACKTYPE<作者の<の個々の><カリフォルニアの<の個々の @?カリフォルニア>カタログ<カタログ><カリフォルニアの>CITATIONTEMPLATE<citationtemp><カリフォルニアの>事務員 hを中止してください?br />
White [Page 34] RFC 524 A Proposed Mail Protocol 13 June 1973
THOSE BORROWED FROM FTP
FTPから借りられた以下のコマンドは'ファイル'における、1つのメールのContentの転送を支持するMPコマンドが形成されると定義されます(また)。 読者はそれらの使用と構文の記述のためのFTPプロトコルドキュメントを参照されます。 借りられたコマンドは以下の通りです。
The following commands borrowed from FTP are defined (also) as MP
commands to support the transfer of the Content of a piece of Mail
in 'file' form. The reader is referred to the FTP protocol
document for a description of their use and syntax. The borrowed
commands are:
バイト、ソックス、PASV、タイプ、STRU、モード、休息、およびサイト。
BYTE, SOCK, PASV, TYPE, STRU, MODE, REST, and SITE.
FTPから借りられた以下のコマンドはMPサブシステムの中で会計パラメタの変化を可能にするMPと定義された(また)コマンドです。 サブシステムが入られると有効な会計パラメタは(必要なら)サブシステムの中で変えるまで適用されます。 事実上、パラメタがサブシステムで変わったかもしれない値はFTPコマンドスペースへのリターンのときに続きます。 借りられたコマンドは以下の通りです。
The following commands borrowed from FTP are defined (also) as MP
commands to permit changes of accounting parameters within the MP
subsystem. The accounting parameters in force when the subsystem
is entered apply (if necessary) within the subsystem until
changed. Values to which the parameters may have been changed
while in the subsystem continue in effect upon return to the FTP
command space. The borrowed commands are:
ユーザ、パス、およびACCT。
USER, PASS, and ACCT.
また、FTPから借りられた以下の種々雑多なコマンドはMPコマンドと定義されます:
The following miscellaneous commands borrowed from FTP are defined
also as MP commands:
助けとNOOP。
HELP and NOOP.
コマンド回答
COMMAND REPLIES
このリストは確かに不完全です。 ユーザと、サーバと応答の間に彼らが必要とするサーバから起こるかもしれない相互作用の種類について見通す作者の試みにもかかわらず、いくつかの重要な回答コード課題がなくなっているかもしれません。
This list is undoubtedly incomplete; some crucial reply code assignments may be missing despite the author's attempt to foresee the kinds of interaction that might arise between user and server and the responses from the server that they would require.
172<は引用コンポーネント>です。
172 <A Citation Component>
終わるEXITコマンドに対応して、Citation Retrievalは機能します。
In response to the EXIT command which terminates the Citation
Retrieval function.
引用の173終わり。
173 End of citation.
172のリストに従うのは返答します。
Following a list of 172 replies.
200 OK。
200 OK.
これはプロトコル中で使用される標準的、そして、積極的な承認です。
This is the standard, positive acknowledgment used throughout
the Protocol.
White [Page 35] RFC 524 A Proposed Mail Protocol 13 June 1973
270 <pathname> -- is assigned as the pathname.
終わるEXITコマンドに対応して、Recordは機能します。
In response to the EXIT command which terminates the Record
function.
271 <functionlist>--支持されています。
271 <functionlist> -- supported.
ユーザ・プロセスがメールサブシステムに入るメールコマンドに対応して。 この応答は義務的です、そして、それから、ユーザ・プロセスはどんな機能がサーバによってサポートされるかをすぐに決定できます。
In response to the MAIL command by which the user process
gains entry to the Mail subsystem. This response is
mandatory, and from it the user process can quickly determine
what function(s) are supported by the server.
272要請者は言う彼が彼が人です。
272 Requestor is who he says he is.
IDに対応して、User Verification機能で命令してください。 与えられているIdはユーザ・プロセスですが、この回答は知らせました、事実上、Individualのものが指定しました。
In response to an ID command in the User Verification
function. This reply informs the user process that the Id
given is in fact that of the Individual specified.
330 OK。 Id、現在、お願いします。
330 OK. Now Id, please.
1番目に対応して、Individual Listのそれぞれの組のコマンドで命令してください。 この回答は、IDになるようにユーザ・プロセスから次のコマンドを必要とします。
In response to the first command in each pair of commands in
an Individual List. This reply requires the next command from
the user process to be ID.
332は最初に、ログインしてください。
332 Login first, please.
メール機能(例えば、RECORD、DISTRIBUTE、DELIVER)を呼び出すどんなコマンドに対応したメールコマンド自体に。 この回答は、要求された機能がサーバによってサポートされますが、それを呼び出す前にユーザがログインしなければならないのを含意します。
In response to any command which invokes a Mail function
(e.g., RECORD, DISTRIBUTE, DELIVER), or to the MAIL command
itself. This reply implies that the requested function is
supported by the server, but that the user is required to
login before invoking it.
実行されないで、400は機能します。
400 Function not implemented.
メール機能(例えば、RECORD、DISTRIBUTE、DELIVER)を呼び出すどんなコマンドに対応したメールコマンド自体に。 この回答は、要求された機能がサーバによってサポートされないのを含意します。
In response to any command which invokes a Mail function
(e.g., RECORD, DISTRIBUTE, DELIVER), or to the MAIL command
itself. This reply implies that the requested function is not
supported by the server.
431 不正確なアイダホ州
431 Incorrect Id.
IDに対応して、Individual Listコマンド組で命令してください。 この回答は、指定されたIdが不正確であったのを含意します。
In response to the ID command in an Individual List command
pair. This reply implies that the Id specified was incorrect.
White [Page 36] RFC 524 A Proposed Mail Protocol 13 June 1973
440 <Error relayed from Recording Agent>
LOCATIONに対応して、命令してください。 この回答は、サーバがFTPサーバから指定された片のメールを検索するのを試みましたが、テキストが現在の回答でコピーされるエラー応答を返したので失敗したのを含意します。
In response to the LOCATION command. This reply implies that
the server attempted to retrieve the specified piece of Mail
from an FTP server but failed because it returned the error
reply whose text is duplicated in the current reply.
そのような470のパス名でない。
470 No such pathname.
PATHNAMEに対応して、命令してください(Citation Retrieval機能で)。 この回答は、指定されたパス名がサーバによって認識されないのを含意します。
In response to the PATHNAME command (in the Citation Retrieval
function). This reply implies that the specified pathname is
not recognized by the server.
471 転送する読まれていないメールがありません。
471 No unRead Mail to Forward.
Forwarding Functionを終えるEXITコマンドに対応して。
In response to the EXIT command which terminates the
Forwarding Function.
472要請者は言う彼が彼が人ではありません。
472 Requestor is NOT who he says he is.
IDに対応して、User Verification機能で命令してください。 この回答は、指定されて、与えられているIdがIndividualのものでないことをユーザ・プロセスに知らせます。
In response to an ID command in the User Verification
function. This reply informs the user process that the Id
given is NOT that of the Individual specified.
473 あなたはメールにRead Accessを持っていません。
473 You don't have Read Access to the Mail.
LOCATIONに対応して、命令するか、またはPATHNAMEに、Citation Retrieval機能で命令してください。 この回答は、Requestorがメールの断片にRead Accessを持っていないのを含意します。
In response to the LOCATION command, or to the PATHNAME
command in a Citation Retrieval function. This reply implies
that the Requestor doesn't have Read Access to the piece of
Mail.
474 受取人認識されていません。 Delivery司令官はOKですか?
474 Recipient unrecognized; is General Delivery OK?
RECIPIENTの例に対応して、Distribution List(Delivery機能の文脈の)で命令してください。 この応答はそれを含意します。認識されていないところのRecipient、ユーザが処理して、サーバが一般を試みていないつもりであったなら、彼へのDeliveryはGENERALDELIVERYコマンドで応じます。 さもなければ、Recipientは拒絶されます。
In response to an instance of the RECIPIENT command in a
Distribution List (in the context of the Delivery function).
This response implies that the Recipient in unrecognized, but
that the server will attempt General Delivery to him if the
user process responds with a GENERALDELIVERY command;
otherwise the Recipient is rejected.
475 そのIndividualはこのホストにありません。
475 That Individual is not at this host.
570 そのようなNIC IdentかMailbox Nameでない。
570 No such NIC Ident or Mailbox Name.
NIC IdentかMailbox Nameが議論として現れるどんなコマンドに対応して。 この回答は、指定されたIndividualが存在しないのを含意します。
In response to any command in which a NIC Ident or Mailbox
Name appears as an argument. This reply implies that the
Individual specified does not exist.
White [Page 37] RFC 524 A Proposed Mail Protocol 13 June 1973
571 Invalid host.
ホスト・アドレスか標準のホスト名が議論として現れるどんなコマンドに対応して。 この回答は、どんなそのようなホストも存在しないのを含意します。
In response to any command in which a host address or standard
host name appears as an argument. This reply implies that no
such host exists.
そのような572個のカタログでない。
572 No such catalog.
CATALOGに対応して、命令してください。 この回答は、どんなそのようなCatalogも存在しないのを含意します。
In response to the CATALOG command. This reply implies that
no such Catalog exists.
どんな'500'も返答します。
Any '500' reply.
エラー応答のいずれもFTP RETR/STORコマンドと交際しました。
Any of the error replies associated with FTP RETR/STOR commands.
正式な構文
FORMAL SYNTAX
実際にメールユーザかサーバの過程を実行する際に使われるべき簡潔なキーワードフォームは、対応する冗長なフォームからキャラクタを削除することによって、作られます。ものは続く記述の間中含まれていましたが、括弧に同封されたキャラクタを削除しました。 空間は、構文の端末の原理の間で自由に使用されて、いくつかのケース、少なくともスペースがそうしなければならない1でそうでなければ境界を区別できなかった2つの要素を切り離すことができます。
The terse keyword forms to be employed in actually implementing a Mail user or server process are generated by deleting character(s) from the corresponding verbose forms. Those deleted characters are included but enclosed in brackets throughout the description which follows. Spaces can be used freely between terminal elements of the syntax, and in some cases, at least one space must separate two elements whose boundary could not otherwise be distinguished.
<CA2>:、:= TELNET Go Aheadキャラクタ<カリフォルニア>:、:= TELNET復帰改行(CR LF)<CRLF>:、:= CR LF<accesstypes>:、:= <readaccess><controlaccess><ackcondition>:、:= [LWAYS]| F[AILURE]| N[かつて]<acktype>:、:= T[アース語]| V[ERBOSE]<動作>:、:= [CTION]| ヌル<カタログ>:、:= <ストリング><citationcomp>:、:= D[ISTRIBUTION]L[IST]| [課税]L[IST]| C[ATALOG]L[IST]| C[ON]T[ENT]| T[ITLE]| C[オミ]M[ENTS]| Au[トール]| Cl[エルク]| C[REATION]D[食べた]<citationtemp>:、:= <citationcomp>。| <citationcomp><citationtemp><コマンド>:、:= <shortbody><カリフォルニア>。| <longbody><CA2><は>について論評します:、:= <ストリング><controlaccess>:、:= C[ONTROLLING]| ヌル<カウント>:、:= 10進整数<日付>:、:= <dayofmonth>/<月の>/<年の><datetime>:、:= <日付の><時間><dayofmonth>:、:= 10進整数、1-31<何日もの>:、:= <カウント>D[賛成]<deliverystatus>:、:= F[苦しめられます]| S[UCCESSFUL]| T[IMEDが外にある状態で]|
<CA2> ::= TELNET Go Ahead character
<CA> ::= TELNET new line (CR LF)
<CRLF> ::= CR LF
<accesstypes> ::= <readaccess> <controlaccess>
<ackcondition> ::= A[LWAYS] | F[AILURE] | N[EVER]
<acktype> ::= T[ERSE] | V[ERBOSE]
<action> ::= A[CTION] | null
<catalog> ::= <string>
<citationcomp> ::= D[ISTRIBUTION]L[IST] | A[CESS]L[IST] |
C[ATALOG]L[IST] | C[ON]T[ENT] | T[ITLE] |
C[OM]M[ENTS] | AU[THOR] | CL[ERK] |
C[REATION]D[ATE]
<citationtemp> ::= <citationcomp> | <citationcomp>
<citationtemp>
<command> ::= <shortbody> <CA> | <longbody> <CA2>
<comments> ::= <string>
<controlaccess> ::= C[ONTROLLING] | null
<count> ::= decimal integer
<date> ::= <dayofmonth> / <month> / <year>
<datetime> ::= <date> <time>
<dayofmonth> ::= decimal integer, 1-31
<days> ::= <count> D[AYS]
<deliverystatus> ::= F[AILED] | S[UCCESSFUL] | T[IMED OUT] |
White [Page 38] RFC 524 A Proposed Mail Protocol 13 June 1973
W[AITING] | U[NATTEMPTED]
<deliverytype> ::= F[ORWARD] | M[AIL] | N[EGATIVE
ACKNOWLEDGMENT] | P[OSITIVE
ACKNOWLEDGMENT] | P[ROGRESS]R[EPORT]
| R[EPLY]
<disposition> ::= <rsvp> <action> <interrupt>
<fileaddr> ::= <host> <pathname>
<functionlist> ::= <functiontype> | <functiontype>
<functionlist>
<functiontype> ::= RE[CORDING] | DE[LIVERY] | DI[STRIBUTION] |
F[OR]W[ARDING] | CI[TATION RETEiEVAL] |
UP[DATE] | U[SER]V[ERIFICATION]
<globalname> ::= * <nicident>
<greeting> ::= <string>
<host> ::= <hostname> | <hostaddress>
<hostaddress> ::= decimal integer, 0-255
<hostname> ::= standard host name
<hour> ::= decimal integer, 0-23
<hours> ::= <count> H[OURS]
<individual> ::= <localname> | <globalname>
<interrupt> ::= I[NTERRUPT] | null
<interval> ::= <days> | <hours> | <days> <hours>
<localname> ::= <mailbox> @ <host> | <mailbox> @
NOTE: Host defaults to that of the server
<longbody> ::= COM[MENTS] <comments> |
TEXT <string>
<mailbox> ::= <string>
<minute> ::= decimal integer, 0-59
<month> ::= decimal integer, 1-12
<nicident> ::= <string>
<id> ::= <string>
<pathname> ::= <string>
<readaccess> ::= R[EAD] | null
<rsvp> ::= R[SVP] | null
<serialnumber> ::= <string>
<shortbody> ::= ABOR[T] |
ACC[ESS] <individual> |
ACKC[ONDITION] <ackcondition> |
ACKT[YPE] <acktype> |
AC[CESS]TY[PES] <accesstypes> |
AUTH[OR] <individual> |
CAT[ALOG] <catalog> |
CLER[K] <individual> |
CR[EATION]DA[TE] <datetime> |
CUT[OFF] <interval> |
C[ITATION]TEM[PLATE] <citationtemp> |
DELI[VER] |
DE[LIVERY]TY[PE] <delivverytype> |
W[AITING]| U[NATTEMPTED]<deliverytype>:、:= F[ORWARD]| M[苦しめます]| N[EGATIVE承認]| P[OSITIVE承認]| P[ROGRESS]R[EPORT]| R[EPLY]<気質>:、:= <rsvp><動作><中断><fileaddr>:、:= <ホスト><パス名><functionlist>:、:= <functiontype>。| <functiontype><functionlist><functiontype>:、:= re[細引きを掛けます]| DE[仕着せ]| ディ[STRIBUTION]| F[OR]W[ARDING]| CI[TATION RETEiEVAL]| [日付]に| U[SER]V[ERIFICATION]<globalname>:、:= * <nicident><挨拶>:、:= <ストリング><ホスト>:、:= <ホスト名>。| <hostaddress><hostaddress>:、:= 10進整数、0-255<ホスト名>:、:= 標準のホスト名<時間>:、:= 10進整数、0-23<何時間もの>:、:= <カウント>H[私たちのもの]の<の個々の>:、:= <localname>。| <globalname><中断>:、:= 私[NTERRUPT]| ヌル<間隔>:、:= <何日もの>。| <何時間もの>。| <日><時間><は>をlocalnameします:、:= <メールボックス>@<ホスト>。| <メールボックス>@注意: サーバ<longbody>のものにデフォルトをホスティングしてください:、:= COM[MENTS]<は>について論評します。| テキスト<は><メールボックス>を結びます:、:= <ストリング><分>:、:= 10進整数、0-59<月の>:、:= 10進整数、1-12<nicident>:、:= <ストリング><イド>:、:= <ストリング><パス名>:、:= <ストリング><readaccess>:、:= R[EAD]| ヌル<rsvp>:、:= R[SVP]| ヌル<serialnumber>:、:= <ストリング><shortbody>:、:= ABOR[T]| ACC[ESS]の<の個々の>。| ACKC[ONDITION]<ackcondition>。| ACKT[YPE]<acktype>。| 交流[課税]TY[PES]<accesstypes>。| AUTH[OR]の<の個々の>。| 猫[Alog]<カタログ>。| CLER[K]の<の個々の>。| CR[EATION]DA[Te]<datetime>。| カット[OFF]<間隔>。| C[ITATION]テム[プレート]<citationtemp>。| デリカテッセン[VER]| DE[仕着せ]TY[PE]<delivverytype>。|
White [Page 39] RFC 524 A Proposed Mail Protocol 13 June 1973
白い[39ページ]RFC524は提案されたメールプロトコル1973年6月13日です。
DISP[OSITION] <disposition> |
DIST[RIBUTE] |
EXIT |
FILE |
FOR[WARDE]E <individual> |
FOR[WARD] |
GEN[ERAL]D[ELIVERY] |
GREE[TING] <greeting> |
ID <ID> |
LOC[ATION] <fileaddr> |
MAIL |
MON[ITOR] <individual> |
PATH[NAME] <pathname> |
RECI[PIENT] <individual> |
REC[ORD] |
REQ[UESTO]R <individual> |
R[EFERENCE]SER[IAL] <serialnumber> |
R[EPORT]INT[ERVAL] <interval> |
SERI[AL] <serialnumber> |
SIGN[ATURE] <signature> |
TITL[E] <title> |
UPDA[TE] |
UP[DATE]TY[PE] <updatetype> |
VER[IFY]
<signature> ::= <string>
<string> ::= any non-zero number of visible characters
(in particular, CA and CA2 are excluded)
<time> ::= <hour> : <minute> <timezone>
<timezone> ::= EST | EDT | CST | CDT | MST | MDT | PST |
PDT | GMT
<title> ::= <string>
<updatetype> ::= A[DD] | R[EPLACE] | D[ELETE]
<year> ::= full year in decimal (e.g., 1973)
DISP[OSITION]<気質>。| DIST[RIBUTE]| 出口| ファイル| [ワード]E<の個々の>で| [区]に| [ERAL]D[ELIVERY]に情報を得てください。| グレー[チリンチリン]<挨拶>。| ID<ID>。| LOC[ATION]<fileaddr>。| メール| 月曜日[ITOR]の<の個々の>。| 経路[名前]<パス名>。| RECI[PIENT]の<の個々の>。| REC[オード川]| REQ[UESTO]のR<の個々の>。| R[EFERENCE]SER[IAL]<serialnumber>。| R[EPORT]INT[ERVAL]<間隔>。| セリ族[AL]<serialnumber>。| サイン[ATURE]<署名>。| TITL[E]<タイトル>。| UPDA[Te]| [日付]TY[PE]<updatetype>に| VER[IFY]<署名>:、:= <ストリング><ストリング>:、:= 目に見えるキャラクタ(特に、カリフォルニアとCA2は除かれる)<時間>のどんな非ゼロ番号も:、:= <時間>: 微小な<の><タイムゾーン><タイムゾーン>:、:= 米国東部標準時| 東部夏時間| CST| CDT| MST| MDT| 太平洋標準時| 太平洋夏時間| グリニッジ標準時の<タイトル>:、:= <ストリング><updatetype>:、:= [DD]| R[EPLACE]| D[ELETE]<年の>:、:= 小数における一年間(例えば、1973)
[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by Root 2/98 ]
[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした][Root2/98によるオンラインRFCアーカイブへの]
White [Page 40]
ホワイト[40ページ]
一覧
スポンサーリンク
