RFC725 日本語訳
0725 RJE protocol for a resource sharing network. J.D. Day, G.R.Grossman. March 1977. (Format: TXT=44025 bytes) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
NWG/RFC# 725 DAY GRG 25-APR-77 12:41 38316 An RJE Protocol for a Resource Sharing Network
NWG/RFC#725のGRG25 4月の77 12日目: リソース・シェアリングネットワークのためのRJEプロトコルあたり41 38316
CAC Technical Memorandum No. 86
CACの技術的なメモNo.86
CCTC-WAD No. 7508
CCTC-固まりのNo.7508
ARPANET RFC No. 725
アルパネットRFC No.725
NIC No. 38316
NIC No.38316
An RJE Protocol for a Resource Sharing Network
リソース・シェアリングネットワークのためのRJEプロトコル
by
by
John Day
ジョンデイ
Gary R. Grossman
ゲーリー・R.グロースマン
Prepared for the
用意をします。
Command and Control Technical Center
指揮統制の技術的なセンター
WWMCCS ADP Directorate
WWMCCS ADP管理職
of the
the
Defense Communications Agency
ディフェンスコミュニケーション代理店
Washington, D.C. 20305
ワシントンDC20305
under contract
契約に基づき
DCAl00-76-C-0088
DCAl00 76C0088
Center for Advanced Computation
高度な計算のためのセンター
University of Illinois at Urbana-Champaign
Urbana-Champaignにおけるイリノイ大学
Urbana, Illinois 61801
アーバナ、イリノイ 61801
March 1, 1977
1977年3月1日
Approved for Release - Peter A. Alsberg, Principal Investigator
リリースのために、承認されました--ピーターA.Alsberg、主任研究者
NWG/RFC# 725 DAY GRG 25-APR-77 12:41 38316 An RJE Protocol for a Resource Sharing Network
NWG/RFC#725のGRG25 4月の77 12日目: リソース・シェアリングネットワークのためのRJEプロトコルあたり41 38316
For many users of the ARPANET, an RJE protocol is probably as important in terms of utility as a TELNET (VTP) protocol. In fact, the facilities provided by a TELNET and an RJE protocol are probably of most interest to most users of computer networks. For these users, the net provides a fast, cheap RJE surrogate, just as TELNET provides a telephone surrogate for the timesharing user. The collection (and layers) of protocols that provide these services must be organized to efficiently support a wide variety of applications and user needs. They should not pose an undue software burden on the user.
アルパネットの多くのユーザにとって、RJEプロトコルはユーティリティでTELNET(VTP)プロトコルとたぶん同じくらい重要です。 事実上、TELNETによって提供された施設とRJEプロトコルはたぶんコンピュータネットワークのほとんどのユーザにほとんどおもしろいです。 これらのユーザのために、ネットは速くて、安いRJE代理を提供します、ちょうどTELNETが電話代理を時分割ユーザに提供するように。 効率的にさまざまなアプリケーションとユーザの必要性をサポートするのをこれらのサービスを提供するプロトコルの収集(そして、層)をまとめなければなりません。 彼らはユーザの上で過度のソフトウェア負担を引き起こすべきではありません。
The "official" NETRJE protocol for the ARPANET has met an underwhelming response from both the user and server community. I believe there are two basic reasons. First, a large commitment of resources is necessary to implement NETRJE. Second, the protocol creates serious security problems.
アルパネットのための「公式」のNETRJEプロトコルはユーザとサーバ共同体の両方から圧倒していない応答を満たしました。 私は、2つの根本的な理由があると信じています。 まず最初に、リソースの大きい委任が、NETRJEを実装するのに必要です。 2番目に、プロトコルは重大な警備上の問題を作成します。
In order to support the ARPA RJE protocol, a user must implement User Telnet, Server FTP, and User RJE, while a server must implement Server Telnet, User FTP, and Server RJE. In addition when an RJE session is going on all three of these protocol implementations will be executing for most of the life of the session. This could entail considerable burden for some systems. Although it may not be out of line to require a service to shoulder such burdens, it is out of line to require a user to assume them in order to gain a rather basic service. Most user installations are oriented toward meeting their user's needs not toward implementing large amounts of network software. (In fact one of the better aspects of the previous ARPANET protocol designs was that they attempted to minimize the work for the user. (It must be admitted though that compassion for the user was not the reason for this approach.)
User RJE、サーバが実装しなければならない間、ARPA RJEプロトコルをサポートするには、ユーザはUser Telnet、Server FTPを実装しなければならなくて、Server Telnet、UserがFTPと、Server RJEであると実装してください。 RJEセッションが経っているときさらに、これらのすべての3つのプロトコル実装がセッションの寿命の大部分の実行になるだろうこと。 これはいくつかのシステムのためにかなりの負担を伴うかもしれません。そのような負担を背負うためにサービスを必要とするのは法外でないかもしれませんが、ユーザがそれらを仮定するのが必要であるのは、かなり基本的なサービスを獲得するために法外です。 多量のネットワークソフトウェアを実装しないことに向かって彼らのユーザの需要を満たすことに向かってほとんどのユーザインストールが適応します。 (事実上、前のアルパネットプロトコルデザインの、より良い局面の1つはユーザのために仕事を最小にするのを試みたということでした。(ユーザに関するその同情はこのアプローチの理由ではありませんでしたが、それを認めなければなりません。)
In order to support a "hot line printer" (i.e., a job is automatically printed when it is completed), the user must store his user code and password for the output host at the server host. This, of course, presents a rather severe security problem. Although the ARPANET can not be made totally secure without massive revision, there are some basic precautions that can be taken to protect users from being victimized by every first year Computer Science student with access to the net.
「ホットラインプリンタ」(完成するとき、すなわち、仕事は自動的に印刷される)をサポートして、ユーザは出力ホストのためにサーバー・ホストに彼のユーザコードとパスワードを保存しなければなりません。 これはもちろんかなり厳しい警備上の問題を提示します。 アルパネットを大規模な改正なしで完全に安全にすることができませんが、すべての1年生のコンピュータScience学生によって犠牲にされるのからネットへのアクセスでユーザを保護するために取ることができるいくつかの基本的な事前注意事項があります。
The RJE protocol proposed here tries to mitigate the implementation problems and security problems. The protocol is designed to provide three levels of service. A user or server has the perogative to implement the protocol at whatever level their resources allow. The service can then be upgraded to cleaner or more sophisticated approaches when and if the opportunity arises.
ここで提案されたRJEプロトコルは実装問題と警備上の問題を緩和しようとします。プロトコルは、3つのレベルのサービスを提供するように設計されています。 ユーザかサーバには、それらのリソースが許容するどんなレベルでもプロトコルを実装するperogativeがあります。 クリーナーにアップグレードしたか、より洗練されたアプローチがいつだったか、そして、機会が起こるなら、サービスはそしてときにそうすることができます。
This protocol is described in terms of the ARPANET. Several aspects of
このプロトコルはアルパネットで説明されます。 いくつかの局面
[page 1]
[1ページ]
NWG/RFC# 725 DAY GRG 25-APR-77 12:41 38316 An RJE Protocol for a Resource Sharing Network
NWG/RFC#725のGRG25 4月の77 12日目: リソース・シェアリングネットワークのためのRJEプロトコルあたり41 38316
the design (such as the reply structure) were made to coincide with existing ARPANET conventions. This was done to facilitate understanding and limit the discussion to the protocol itself. Although the protocol is described in ARPANET terms, it should be applicable to other network environments.
デザイン(回答構造などの)は既存のアルパネットコンベンションと同時に起こらされました。 分かるのを容易にして、議論をプロトコル自体に制限するためにこれをしました。 プロトコルはアルパネット用語で説明されますが、それは他のネットワーク環境に適切であるべきです。
This paper is not considered to be complete in every detail. It was written primarily to elicit comments from the network community and to measure the desire of the community to adopt such a procedure. We have tried to describe enough of the protocol so that the reader can get an idea of how things are to work without getting bogged down in the detail that would be necessary for implementation. Below is an outline of the final protocol document as presently conceived. Sections marked with an asterisk are to be provided later.
この紙があらゆる詳細に完全であると考えられません。 それは、ネットワーク共同体からコメントを主として引き出して、共同体がそのような手順を取り入れる願望を測定するために書かれました。 私たちは、読者がことがどう実装に必要な詳細に泥沼に落ち込まれないで働くかことであることを理解できるように、プロトコルについて十分説明しようとしました。 以下に、最終的なプロトコルドキュメントのアウトラインが現在発想されているとしてあります。 アスタリスクでマークされたセクションは後で提供されることになっています。
[page 2]
[2ページ]
NWG/RFC# 725 DAY GRG 25-APR-77 12:41 38316 An RJE Protocol for a Resource Sharing Network
NWG/RFC#725のGRG25 4月の77 12日目: リソース・シェアリングネットワークのためのRJEプロトコルあたり41 38316
Introduction
序論
Part I
部分I
The NETRJE Models
NETRJEモデル
1. Telnet (VTP) Model
1. telnet(VTP)モデル
2. Telnet with Data Transfer Model
2. データ転送モデルがあるtelnet
3. Telnet with FTP Model
3. FTPモデルがあるtelnet
Scenarios for the Models
モデルのためのシナリオ
* Suggested Implementaton Schemes for Various Applications
* 様々なアプリケーションの提案されたImplementaton体系
Part II
パートII
The Server RJE Commands
サーバRJEコマンド
* General Conventions
* 総会
Commands
コマンド
Replies
返信
Numerical List
数字のリスト
Command-Reply List
コマンド回答リスト
* Details of the Data Transfer
* データ転送の詳細
* Minimal Requirements for a User RJE
* ユーザRJEのための最小量の要件
* Minimal Requirements for a Server RJE
* サーバRJEのための最小量の要件
* Glossary of Terms
* 用語の用語集
[page 3]
[3ページ]
NWG/RFC# 725 DAY GRG 25-APR-77 12:41 38316 An RJE Protocol for a Resource Sharing Network
NWG/RFC#725のGRG25 4月の77 12日目: リソース・シェアリングネットワークのためのRJEプロトコルあたり41 38316
Part I THE NETRJE MODELS ------------------------
I NETRJEモデルを分けてください。------------------------
This section describes the proposed NETRJE protocol in a narrative form. A formal definition will be included in Part II after review. The narrative should provide the general reader with the flavor of the protocol without getting bogged down in unnecessary detail. The proposed NETRJE protocol provides three different models for job submission and retrieval. The three models can be characterized as 1) RJE using Telnet only, 2) RJE using Telnet and Data Transfer, and 3) RJE using FTP. This approach provides flexibility for both implementors and users. User and server sites constrained by manpower or machine resources may implement only the simpler models. The user may use the different models separately or in any consistent combination which best suits his requirements and convenience. Servers should assume that the minimal implementation of a more sophisticated model includes the minimal implementations of all less sophisticated models. (There are, however, certain minimal requirements that must be supported.) This secton will discuss each of these models in turn, and show each one can be used to provide a useful network RJE functon.
このセクションは報告様式で提案されたNETRJEプロトコルについて説明します。 公式の定義はレビューの後にPart IIに含まれるでしょう。 詳細に不要な泥沼に落ち込まれないで、物語はプロトコルの風味を一般読者に提供するべきです。 提案されたNETRJEプロトコルは3つの異なったモデルをジョブ依頼と検索に提供します。 1として)3つのモデルについて描写できます。 Telnetだけを使用するRJE、2) telnet、データ転送、および3を)使用するRJE FTPを使用するRJE。 このアプローチは作成者とユーザの両方に柔軟性を提供します。 労働力かマシンリソースによって抑制されたユーザとサーバサイトは、より簡単なモデルだけを実装するかもしれません。 ユーザは別々にか彼の要件と都合が良いときに最もよく合うどんな一貫した組み合わせにも異なったモデルを使用するかもしれません。 サーバは、より精巧なモデルの最小限の器具がすべてのそれほど精巧でないモデルの最小限の器具を含んでいると仮定するべきです。 (しかしながら、サポートしなければならないある最小量の要件があります。) このsectonは、順番にこれらのモデル各人について議論して、役に立つネットワークRJE functonを提供するためにそれぞれを使用できるのを示すでしょう。
This protocol does not contain the security difficulties of the present protocol. This has been avoided by requiring that the burden of implementing the "hot line printer" or "hot card reader" be put on the user system. Thus, those systems which desire such a facility may still support it. The user implementaton will be slightly more complicated. The trade-off is the increased security of the protocol.
このプロトコルは現在のプロトコルのセキュリティ困難を含んでいません。 「熱いラインプリンタ」か「熱いカードリーダ」を実装する負担がユーザシステムに置かれるのを必要とすることによって、これは避けられました。 したがって、そのような施設を望んでいるそれらのシステムはまだそれをサポートしているかもしれません。 ユーザimplementatonはわずかに複雑になるでしょう。 トレードオフはプロトコルの増強されたセキュリティです。
End-to-end protocols are assumed to be available and to provide an ordered, error free bit stream to the RJE protocol. It is also assumed that a suitable virtual terminal protocol such as Telnet, is used to format the control connection.
利用可能であり、終わりから終わりへのプロトコルが注文されて、エラーのないビットストリームをRJEプロトコルに提供すると思われます。 また、Telnetなどの適当な仮想端末プロトコルがコントロール接続をフォーマットするのにおいて使用されていると思われます。
RJE Using Only Telnet (VTP) ---------------------------
telnet(VTP)だけを使用するRJE---------------------------
The intent of this model is, bluntly, to provide an official "quick and dirty" form of the protocol. Many organizatons, both users and servers, are often confronted with problem of providing a service quickly or within very tight budgetary constraints. This model is intended for these situations. With this model, the user is required only to be able to establish a Telnet connection via the RJE contact socket. Commands, replies, and data are all sent over the Telnet connecton. Card input or printer output has the appearance of coming from or going to the user's terminal. The user's system may allow output to be diverted from the terminal to another device such as the line printer. The technique of diverting terminal output was used with great success in the MARK I ANTS
プロトコルの公式の「迅速で汚い」フォームを提供するために、このモデルの意図はつっけんどんにあります。 多くのorganizatons(ユーザとサーバの両方)がすばやくサービスを提供するという問題、または、非常にきつい予算の規制の中でしばしば立ち向かわれています。 このモデルはこれらの状況のために意図します。 このモデルと共に、ユーザはRJE接触ソケットを通してTelnet接続を確立するだけでよいことができます。 コマンド、回答、およびデータをTelnet connectonの上にすべて送ります。 カード入力かプリンタ出力には、ユーザの端末に来るか、または行く外観があります。 ユーザのシステムは、出力が端末からラインプリンタなどの別のデバイスに紛らされるのを許容するかもしれません。 期末生産高を紛らすテクニックは大成功でマークI ANTSで使用されました。
[page 4]
[4ページ]
NWG/RFC# 725 DAY GRG 25-APR-77 12:41 38316 An RJE Protocol for a Resource Sharing Network
NWG/RFC#725のGRG25 4月の77 12日目: リソース・シェアリングネットワークのためのRJEプロトコルあたり41 38316
systems where various devices were not assigned socket numbers as in a TIP. This technique is also useful for hosts that allow program access to the network only through the user's Telnet connection. This situation may exist in the early phases of a server's availability to the network. When data is transferred in this mode an end-of-data marker will be sent to aid the receiving host in determining when to stop diverting the data. This model will have to handle the problems of data traveling on a connection essentially meant for control. The use of this data transfer mechanism is intended as an intermediate measure required by limited resources. For now we let it stand that the designers are aware of the problems inherent in embedding commands or replies in the data stream. We will leave the exact resolution of the problem to the formal definition.
ソケット番号がTIPのように様々なデバイスに割り当てられなかったシステム。 また、このテクニックもユーザのTelnet接続にネットワークへのプログラムアクセスの通ることを許すだけであるホストの役に立ちます。 この状況はサーバの有用性の早めのフェーズでネットワークに存在するかもしれません。 このモードでデータを移すとき、データを紛らすのをいつ止めるかを決定する際に受信ホストを支援するためにデータ終了記号を送るでしょう。 このモデルはデータがコントロールのために本質的には意味された接続に移動するという問題を扱わなければならないでしょう。 中間的測定が限りある資源が必要であるようにこのデータ転送メカニズムの使用は意図します。 当分、私たちは削除を取り消します。デザイナーはコマンドか回答をデータ・ストリームに埋め込むことの固有である問題を意識しています。 私たちは問題の正確な解決を公式の定義に残すつもりです。
This proposed NETRJE protocol uses a schedule verb, SCHED for job submission. For this model, there are two forms of SCHED that are relevant. First, there is the "SCHED <server pathname>" form. This command indicates to the server that there exists at the server site a file with all necessary job control information and data to define a job. The server will then attempt to place the job in the job queue and reply to the user indicating success or failure and possibly a job-id. This job-id will be used when inquiring about the job status or retrieving the job's output.
この提案されたNETRJEプロトコルはジョブ依頼にスケジュール動詞、SCHEDを使用します。 このモデルのために、関連SCHEDの2つのフォームがあります。 まず最初に、「SCHED<サーバパス名>」フォームがあります。 このコマンドは、すべての必要なジョブ制御情報とデータがあるファイルが仕事を定義するためにサーバサイトに存在するのをサーバに示します。 そして、サーバは、仕事をジョブキューに置いて、成否を示すユーザとことによると仕事イドに答えるのを試みるでしょう。 地位について問い合わせをするか、または仕事の出力を検索するとき、この仕事イドは使用されるでしょう。
When the job finishes, the server will take one of two actions:
仕事が終わると、サーバは2つの動作の1つを取るでしょう:
a) if the user is still logged in, the server will send a reply notifying the user of his job completion; or,
a) ユーザがまだログインされていると、サーバで、回答は彼の仕事の完成についてユーザに通知するでしょう。 または
b) if the user is not logged in, the server will save the status of the job which may later be interrogated via the STATUS command (see below).
b) ユーザがログインされないと、サーバは後でSTATUSコマンドで査問されるかもしれない仕事の状態を保存するでしょう(以下を見てください)。
The otherform of SCHED of relevance to this model has the syntax:
このモデルへの関連性のSCHEDのotherformには、構文があります:
SCHED INPUT <CRLF><data><CRLF>.<CFLF>
SCHED入力<CRLF><データ><CRLF><CFLF>。
This allows the user to sit down at a terminal and type his own job control or possibly a program. It also allows those users whose local systems provide a facility to transmit files with User TELNET to transmit user input job fles in this way. The RJE Server would insert the job into the local job stream, returning the proper indication of success or failure along with identification of the job.
これで、ユーザは、端末に座って、彼自身のジョブ制御かことによるとプログラムをタイプします。 また、それはローカルシステムがこのようにユーザ入力仕事のflesを伝えるためにUser TELNETと共にファイルを送るために施設を提供するそれらのユーザを許容します。 RJE Serverはローカルのジョブストリームに仕事を挿入するでしょう、仕事の識別に伴う成否の適切なしるしを返して。
Just as the SCHED command provides several ways for job submission, the OUTPUT command provides several options for retrieving output. The form
ちょうどSCHEDコマンドがジョブ依頼のためのいくつかの方法を提供するように、OUTPUTコマンドは出力を検索するためのいくつかのオプションを提供します。 フォーム
[page 5]
[5ページ]
NWG/RFC# 725 DAY GRG 25-APR-77 12:41 38316 An RJE Protocol for a Resource Sharing Network
NWG/RFC#725のGRG25 4月の77 12日目: リソース・シェアリングネットワークのためのRJEプロトコルあたり41 38316
OUTPUT<job-id><server pathname>DISCARD
出力<仕事イド><サーバパス名>は捨てます。
is sent to the server to initiate the output to the user's site according to output specifications defined by previous OUTDEF commands (see below). The optional DISCARD argument to the OUTPUT command indicates, if present, that the file is to be destroyed after transmission has completed successfully.
前のOUTDEFコマンド(以下を見る)で定義された出力仕様通りにユーザのサイトに出力を開始するためにサーバに送ります。 トランスミッションが破壊した後に破壊されて、首尾よく完成されて、存在しているならコマンドがファイルがそうであることを示すOUTPUTへの任意のDISCARD議論。
The OUTDEF command for a job may be sent at any time after the job has been scheduled and before it is retrieved using the OUTPUT command. This command will specify the parameters necessary to effect the transfer of the output to the user or to define the disposition of the output. We realize that the OUTDEF <job-id><server pathname> command (indicating that output is to be placed in a file described by the pathname) may be difficult for some systems to implement. These systems would merely respond negatively indicating their inability to perform the function.
仕事を予定した後とOUTPUTコマンドを使用することでそれを検索する前にいつでも、仕事のためのOUTDEFコマンドを送るかもしれません。 このコマンドは出力の転送にユーザに作用するか、または出力の気質を定義するのに必要なパラメタを指定するでしょう。 私たちは、OUTDEF<仕事イド><サーバパス名>が、いくつかのシステムに、(出力がパス名によって説明されたファイルに置かれることであることを示します)は実装するのが難しいかもしれないと命令するとわかります。 これらのシステムは、否定的に機能を実行できないことを示しながら、単に反応するでしょう。
A scenario is now in order to illustrate the model. The user has logged in to Multics and is ready to submit an RJE job in the following way (XXX will denote the as yet unspecified reply code for the reply):
シナリオは、モデルを例証する現在です。 ユーザがMulticsにログインして、以下の方法でRJE仕事を提出する準備ができている、(XXXが指示する、回答のためのまだ不特定の回答コード)、:
SCHED MY-JOB>TREK
SCHED、私、-仕事の>は長旅します。
The system responds with a reply indicating the job has been submitted successfully and returns a job-id, say XA1423.
XA1423は、回答が、仕事が首尾よく提出して、仕事イドを返すのを示していてシステムが反応すると言います。
XXX JOB XA1423 was successfully submitted.
首尾よくXXX JOB XA1423を提出しました。
At some later time a message appears.
何らかの後の時間に、メッセージは現れます。
XXX JOB XA1423 has completed.
XXX JOB XA1423は完成しました。
The user or user process now sends OUTDEF XA1423 TELNET indicating that the job should be sent on the TELNET connection. A reply returns
ユーザかユーザ・プロセスで、OUTDEF XA1423 TELNETは、現在、仕事がTELNET接続に送られるべきであるのを示します。 回答は戻ります。
XXX last command successful.
XXXはうまくいった状態でコマンドが続きます。
The user now sends
ユーザは現在、発信します。
OUTPUT XA1423
出力XA1423
and the server replies with
そして、サーバは返答します。
XXX Output ready. Type an empty line when ready.
XXX Output準備ができています。 準備ができているときには空の系列をタイプしてください。
The user then sends an empty line when he is read to receive the output.
そして、出力を受け取るために読まれるとき、ユーザは空の系列を送ります。
[page 6]
[6ページ]
NWG/RFC# 725 DAY GRG 25-APR-77 12:41 38316 An RJE Protocol for a Resource Sharing Network
NWG/RFC#725のGRG25 4月の77 12日目: リソース・シェアリングネットワークのためのRJEプロトコルあたり41 38316
This exchange allows the user to effect output diversion at his local site if necessary after he has confirmed the server is ready.
この交換で、必要なら、サーバが準備ができていると確認した後にユーザは彼のローカル・サイトで出力転換に作用できます。
If the user had not wished to wait on his output and had logged off after getting the successful submission, the next time the user logged in he could inquire as to the status of the job or all jobs under his usercode and then proceeded to output any or all of them.
ユーザが彼の出力で待っていることを願っていなくて、うまくいっている服従を得た後にログオフしたなら、彼は、ユーザがログインした次の時にいずれかそれらを皆、彼のusercodeの下の仕事かすべての仕事の状態に関して問い合わせることができて、出力しかけました。
RJE with TELNET and Data Transfer ---------------------------------
telnetとデータ転送があるRJE---------------------------------
The previous model provided a minimal implementation for NETRJE. This model provides better data transfer facilities without requiring an FTP implementation. This model requires no new commands, but does manipulate connections differently, so that data is not required to flow on the command connection (see Fig. 2). Data is sent on separate default connections (unless otherwise specified) as in the CCN NETRJS protocol. However, for this protocol the defaults used will be the same offsets from the control connection as those in FTP.
従来モデルは最小限の器具をNETRJEに供給しました。 FTP実装を必要としないで、このモデルは、より良いデータ転送施設を提供します。 このモデルは、どんな新しいコマンドも必要としませんが、接続を異なって操ります、データはコマンド接続のときに流れるのに必要でない(図2を参照する)ように。 CCN NETRJSプロトコルのように別々のデフォルト接続(別の方法で指定されない場合)にデータを送ります。 しかしながら、このプロトコルのために、使用されるデフォルトはFTPにおけるそれらとしてのコントロール接続から同じオフセットになるでしょう。
The use of this model is indicated to the Server by either the INDEF command or a SCHED command with no arguments. The INDEF command allows the user to specify a socket other than the default socket as the source of the input. On receipt of the SCHED or INDEF indicating this technique is to be used, the Server will attempt to connect to the appropriate socket. If a SCHED command was sent, the user protocol interpreter could start sending cards as soon as the data connection is established. (It is assumed that the user interface has indicated to the RJE protocol interpreter where the cards are to come from.) If the command was INDEF, then the Server will not start reading until the SCHED is received. Similarly, when the output is ready, either an OUTDEF or OUTPUT command is sent to set up and start the printing. The INDEF and OUTDEF commands used with this mode will also allow moving data to or from a TIP or printer.
このモデルの使用は議論なしでServerにINDEFコマンドかSCHEDコマンドのどちらかで示されます。 INDEFコマンドで、ユーザは入力の源としてのデフォルトソケット以外のソケットを指定できます。 このテクニックが使用されていることであることを示すSCHEDかINDEFを受け取り次第、Serverは、適切なソケットに接続するのを試みるでしょう。 SCHEDコマンドを送るなら、ユーザプロトコルインタプリタは、データ接続が確立されるとすぐに、カードを送り始めることができるでしょうに。 (ユーザーインタフェースが、カードが来ることになっているインタプリタについて議定書の中で述べるようにRJEに示したと思われます。) コマンドがINDEFであったなら、SCHEDが受け取られているまで、Serverは読み始めないでしょう。 出力が準備ができているとき、同様に、印刷をセットアップして、始動するためにOUTDEFかOUTPUTコマンドのどちらかを送ります。 また、コマンドがこのモードで使用したINDEFとOUTDEFはプリンタかTIPかプリンタからの感動的なデータを許容するでしょう。
This model requires definiton of actual data transfer formats for the reader and printer lines. We propose that the formats and connection schemes of the present FTP be adopted. This solution has the advantage of not requiring extra coding efforts for users with FTP implementations and may allow them to organize their FTP implementations and may allow them to organize their FTP and NETRJE implementations in such a way as to take advantage of common algorithms. One might easily confuse this solution with a revival of the Data Transfer Protocol. Some thought on a more rigorous definition of a Data Transfer Protocol for the common use of FTP and RJE might be worthwhile in the future.
このモデルは読者とプリンタ系列のための実際のデータ転送フォーマットをdefinitonに要求します。 私たちは、現在のFTPの形式と接続体系が採用されるよう提案します。 このソリューションは、一般的なアルゴリズムを利用するほどユーザのためにFTP実装で付加的なコード化取り組みを必要としない利点を持って、自己のFTP実装を組織化するのを許容して、そのような方法でそれらのFTPとNETRJE実装を組織化するのを許容するかもしれません。1つは容易にData Transferプロトコルの復活にこのソリューションを間違えるかもしれません。 或るものはFTPの一般の使用のためのData Transferプロトコルの、より厳しい定義を思い出しました、そして、RJE将来、価値があるかもしれません。
[page 7]
[7ページ]
NWG/RFC# 725 DAY GRG 25-APR-77 12:41 38316 An RJE Protocol for a Resource Sharing Network
NWG/RFC#725のGRG25 4月の77 12日目: リソース・シェアリングネットワークのためのRJEプロトコルあたり41 38316
Let us consider a scenario.
シナリオを考えましょう。
The user wishes to submit a card deck to the Server. He then types
ユーザはServerにカードデックを提出したがっています。次に、彼はタイプします。
SCHED<CRLF>
SCHED<CRLF>。
The Server opens a connection to the user's default card reader socket while sending a reply to the user on the control connection.
Serverはコントロール接続のときにユーザに返信している間、ユーザのデフォルトカードリーダソケットに接続を開きます。
XXX attempting connection to card reader.
カードリーダに接続を試みるXXX。
When the connection is opened, another reply:
接続が開かれるとき、別のものは返答します:
XXX transfer started
XXX転送は始まりました。
and when completed:
完成したいつ:
XXX JOB XA 1423 was successfully submitted.
首尾よくXXX JOB XA1423を提出しました。
When the job completes and the completion message is sent to the user, he may wish to send the output to his TIP printer on socket Y. He will then type
仕事が完成するいつ、彼は、完了メッセージをユーザに送って、次にタイプするソケットY.でTIPプリンタに出力を送りたがっているかもしれないか。
OUTDEF XA1423 255, Y (255 being his host address).
OUTDEF XA1423 255、Y(彼のホスト・アドレスである255)。
The Server will then attempt to connect to the socket and will reply
Serverは次に、ソケットに接続するのを試みて、返答するでしょう。
XXX printer connection successful.
XXXプリンタ接続うまくいきます。
When the user has satisfied himself all is in readiness, he will type
彼は、ユーザが納得したとき、すべてが準備中であることをタイプするでしょう。
OUTPUT XA1423
出力XA1423
and the Server will start sending and reply to the user
そして、Serverは発信し始めて、ユーザに答えるでしょう。
XXX print started.
XXX印刷は始まりました。
When the transfer is complete the Server will close the data connection and send an appropriate reply.
転送が完全であるときに、Serverはデータ接続を終えて、適切な回答を送るでしょう。
[page 8]
[8ページ]
NWG/RFC# 725 DAY GRG 25-APR-77 12:41 38316 An RJE Protocol for a Resource Sharing Network
NWG/RFC#725のGRG25 4月の77 12日目: リソース・シェアリングネットワークのためのRJEプロトコルあたり41 38316
NETRJE Using FTP ----------------
FTPを使用するNETRJE----------------
This model (illustrated in Fig. 3) uses FTP to effect the transfer of the files. It may be easier for some systems to use this sort of model for more sophisticated RJE systems. This is especially true if the users desire to take input from the local file system or to send output to the local file system rather than from an actual card reader or to an actual line printer. Although using the local file system is not prohibited by the Data Transfer model, it may be easier to approach through FTP. Using FTP with NETRJE also allows the utilization of the FTP server-server transfer mechanism to generate input from or direct output to a third host.
このモデル(図3では、例証される)は、ファイルの転送に作用するのにFTPを使用します。 いくつかのシステムが、より精巧なRJEシステムにこの種類のモデルを使用するのは、より簡単であるかもしれません。ユーザが、ローカルファイルシステムから入力を取るか、または実際のカードリーダからというよりむしろローカルファイルシステム、または、実際のラインプリンタに出力を送ることを望んでいるなら、これは特に本当です。 使用しますが、ローカルファイルシステムはData Transferモデルによって禁止されていなくて、FTPを通してアプローチするのは、より簡単であるかもしれません。 また、NETRJEがあるFTPを使用すると、生成するトランスファ・メカニズムが出力を入力されるか、または3分の1にホスティングするよう指示するFTPサーバサーバの利用は許されます。
The only new facility required by this model are the commands INPATH and OUTPATH. When using FTP to transfer input to the Server, the user must know where to send the job so that it enters the job stream. The INPATH command returns as a reply such a legal pathname. Thus the scenario for job submission is as follows: The user sends an INPATH command; the Server responds with a legal Server pathname for the user. The user process starts sending the input to the file using FTP. When transfer is complete, the user sends a SCHED <server pathname> command. When the job has finished, the pathname created for the user may or may not destroy the input file. The OUTPATH command is similarily used to identify the pathname for the output, so that it may be retrieved by FTP. Some systems may define file names in such a way that the user may derive them from the parameters of his job.
このモデルによって必要とされた唯一の新しい施設が、コマンドのINPATHとOUTPATHです。 Serverに入力された転送にFTPを使用するとき、ユーザは、それがジョブストリームに入るように仕事をどこに送るかを知らなければなりません。 INPATHコマンドは回答としてそのような法的なパス名を返します。 したがって、ジョブ依頼のためのシナリオは以下の通りです: ユーザはINPATHコマンドを送ります。 Serverはユーザのために法的なServerパス名で応じます。 ユーザ・プロセスは、FTPを使用することで入力をファイルに送り始めます。 転送が完全であるときに、ユーザはSCHED<サーバパス名>コマンドを送ります。 仕事が終わったとき、ユーザのために作成されたパス名は入力ファイルを無効にするかもしれません。 OUTPATHコマンドは出力のためにパス名を特定するのにsimilarilyに使用されます、FTPでそれを検索できるように。 いくつかのシステムがユーザがそれらに彼の仕事のパラメタに由来しているかもしれないような方法でファイル名を定義するかもしれません。
Note on Replies
回答に関する注
In all of the above examples we have refrained from defining actual reply codes. The intent is to use the same reply structure, and where appropriate the same numbers, as described in RFC 640 "Revised FTP Reply Codes".
上記の例では、全部で、私たちは、実際の回答コードを定義するのを控えました。 意図が同じ回答構造を使用することであり、どこが同じ適切な数であるか、RFC640「改訂されたFTP回答コード」で説明されるように。
Protocol Measurement
プロトコル測定
An integral part of any good protocol definition is a set of measurements to allow evaluation of both the protocol and its implementation. This provides two functions: 1) It allows the protocol designer to evaluate the protocol and make improvements. 2) It allows the user of the protocol to know how expensive it is and to demand improvements. The proposed NETRJE protocol provides two sets of measures - one for a particular session and one for overall performance. These measurements may be elicited by the MEASURE command which will take an argument with three values: JOB (job statistics and cost measurements), SESSION (measurements taken for this sesson), and GLOBAL
どんな良いプロトコル定義の不可欠の部分もプロトコルとその実装の両方の評価を許す1セットの測定値です。 これは2つの機能を提供します: 1) それで、プロトコルデザイナーは、プロトコルを評価して、改良をします。 2) それで、プロトコルのユーザは、それがどれくらい高価であるかを知って、改良を要求します。 提案されたNETRJEプロトコルは2セットの測定を提供します--特定のセッションのためのものと総合的な性能のためのもの。 これらの測定値は3つの値との議論を取るMEASUREコマンドで引き出されるかもしれません: JOB(仕事の統計と原価測定)、SESSION(このsessonに取られた測定値)、およびGLOBAL
[page 9]
[9ページ]
NWG/RFC# 725 DAY GRG 25-APR-77 12:41 38316 An RJE Protocol for a Resource Sharing Network
NWG/RFC#725のGRG25 4月の77 12日目: リソース・シェアリングネットワークのためのRJEプロトコルあたり41 38316
(overall measurements of the performance of the protocol and its implementation). The command will return the measurements in a fixed format reply.
(プロトコルとその実装の性能の総合的な測定値。) コマンドは固定フォーマット回答における測定値を返すでしょう。
The measurements reported for a job are:
仕事のために報告された測定値は以下の通りです。
1. CPU time,
1. CPU時間
2. I/O operations,
2. 入出力操作
3. storage space time product,
3. 集積スペース時間製品
4. job cost in dollars,
4. ドルで表現される個別原価
5. elapsed time the job waited before being executed, and
そして5. 実行される前に仕事が待った経過時間。
6. elapsed time for the job to execute.
6. 仕事が実行する経過時間。
The measures taken from a sesson are:
sessonから実施される対策は以下の通りです。
1. number of bits transferred,
1. ビットの数は移されました。
2. transmission rate of input or output transfers,
2. 入力か出力の通信速度は移されます。
3. the amount of CPU time, storage space-time product, and I/O operations for the session.
3. CPU時間の量、ストレージ時空製品、およびセッションのための入出力操作。
4. cost in dollars and cents.
4. ドルとセントで表現される費用。
The measures to be taken globally are:
とるべき対策はグローバルに以下の通りです。
1. frequency of commands and possibly command forms,
1. コマンドとことによるとコマンドの頻度は形成されます。
2. model frequency (which submission/retrieval model used),
2. 頻度(服従/検索モデルが使用した)をモデル化してください。
3. transmission mode frequency,
3. 転送方式頻度
4. total number of sessions,
4. セッションの数を合計してください。
5. transmission rate: average, std. deviation, upper and lower bounds (also by transmission mode),
5. 通信速度: 平均、std逸脱、上下の領域(転送方式によっても)
6. cpu time, storage space-time product, and I/O operations for both the protocol and jobs submitted: average, std. deviation, and upper and lower bounds (overall as well as by model, transfer mode, and file size). (The reason for including job statistics here is so that
6. cpu time、ストレージ時空製品、およびプロトコルと仕事の両方のための入出力操作は提出されました: 平均、std逸脱、および上下の領域(全体的に見て、そして、モデル、転送モード、およびファイルサイズに従った)。 (賃仕事の統計を含んでいて、したがって、それがここにいるので、推論してください。
[page 10]
[10ページ]
NWG/RFC# 725 DAY GRG 25-APR-77 12:41 38316 An RJE Protocol for a Resource Sharing Network
NWG/RFC#725のGRG25 4月の77 12日目: リソース・シェアリングネットワークのためのRJEプロトコルあたり41 38316
management and systems personnel have some indication how the facility is being used.)
管理とシステム人員には、施設が使用されている何らかの指示があります。)
It is clear that it may be difficult to acquire some measures (such as transmission rate) when NETRJE is using FTP. This is unavoidable since FTP is not metered. The most straightforward solution is also to meter FTP (hint). For the final definition a close look will be given to the subset that should be required. Comments are welcome. However, we believe strongly that it is very important to know how a facility like this is used as well as how well it performs.
NETRJEがいつFTPを使用しているかは、いくつかの測定(通信速度などの)を入手するのが難しいかもしれないのが明確です。 FTPが計量されないので、これは避けられません。 最も簡単なソリューションはまた、FTP(ヒント)を計量することです。 最終的な定義において、必要であるべきである部分集合によく見るのを与えるでしょう。 コメントを歓迎します。 しかしながら、私たちは、どれくらいよく働くかと同様にこのような施設がどのように使用されるかを知るのが非常に重要であると強く信じています。
[page 11]
[11ページ]
NWG/RFC# 725 DAY GRG 25-APR-77 12:41 38316 An RJE Protocol for a Resource Sharing Network
NWG/RFC#725のGRG25 4月の77 12日目: リソース・シェアリングネットワークのためのRJEプロトコルあたり41 38316
Part II. Preliminary Definition of NETRJE Commands ---------------------------------------------------
IIを分けてください。 NETRJEコマンドの予備の定義---------------------------------------------------
For purposes of discussion this section gives a very preliminary definition of the NETRJE commands and their replies. The intent is to give a brief but not exhaustive definition of each command and its major replies to give the flavor of the protocol. We do not do this to discourage nit-picking by critics, since we may actually overlook the obvious on occasion, but merely to expedite the writing of this paper.
議論の目的のために、このセクションはNETRJEコマンドと彼らの回答の非常に予備の定義を与えます。 意図はプロトコルの風味を与えるために遺漏のない定義ではなく、各コマンドとその主要な回答の要約を与えることです。 私たちは、私たちが時々実際に明白を見落とすかもしれないので評論家によるこまかいことへのこだわりに水をさしているためにこれをするのではなく、単にこの紙の書くことを速めるためにします。
The reply scheme will follow the model of the revised FTP reply codes described in RFC 640.
回答体系はRFC640で説明された改訂されたFTP回答コードのモデルに従うでしょう。
Access Control
アクセス制御
USER <usercode>
ユーザ<usercode>。
PASS <password>
<パスワード>を渡してください。
ACCT <account>
ACCT<アカウント>。
These perform the normal functions to log the user into the system. The replies to them are the standard ones in FTP. It was never clear why "account" was not included in the old NETRJE. Presumably, if it's necessary for an FTP or Telnet user, it will be necessary for an RJE user.
これらは、システムにユーザを登録するために正規曲線を実行します。 それらに関する回答はFTPで標準のものです。 「アカウント」がなぜ古いNETRJEに含まれていなかったかは、決して明確ではありませんでした。 おそらく、それがFTPかTelnetユーザに必要であるなら、RJEユーザに必要になるでしょう。
REINIT
REINIT
This command reinitializes the state of the NETRJE server process so that it is ready for a new user. If the transfer of data is in progress for the previous user, it will be allowed to complete.
このコマンドがNETRJEサーバプロセスの状態を再初期化するので、それは新しいユーザの準備ができています。 データ転送が前のユーザにとって進行していると、それは完全な状態で許容されるでしょう。
ABORT
アボート
This command is used to abort the transfer of data. This command is meaningful to the Server only if the data is being transferred over the Telnet connection or the default data sockets. If FTP is being used, the execution of this command is the responsibility of the USER NETRJE process.
このコマンドは、データ転送を中止するのに使用されます。 Telnet接続かデフォルトデータソケットの上にデータを移している場合にだけ、このコマンドはServerに重要です。 FTPが使用されているなら、このコマンドの実行はUSER NETRJEプロセスの責任です。
BYE
さようなら
This command causes the Server to log out the user and close the Telnet connection. If the transfer of data is in progress, the action of the command will be delayed until the transfer is complete.
このコマンドは、Serverがユーザをログアウトして、Telnet接続を終えることを引き起こします。 データ転送が進行していると、転送が完全になるまで、コマンドの動作は遅れるでしょう。
[page 12]
[12ページ]
NWG/RFC# 725 DAY GRG 25-APR-77 12:41 38316 An RJE Protocol for a Resource Sharing Network
NWG/RFC#725のGRG25 4月の77 12日目: リソース・シェアリングネットワークのためのRJEプロトコルあたり41 38316
SCHED <input part><output part>
SCHED<入力パート><出力パート>。
<input part>::= <empty>|<server pathname> [DISCARD]
<はパート>を入力しました:、:= <空です。>|<サーバパス名>。[破棄]
INPUT <CRLF> <text> <CRLF>.<CRLF>
><CRLF>入力<CRLF><テキスト<CRLF>。
output part ::= <empty>|<server pathname>[DISCARD]
出力されて、以下を分けてください:= <空です。>|<サーバパス名>。[破棄]
server pathname ::= {locally recognizable string of characters
terminated by an ASCII NULL}
サーバパス名:、:= ASCII NULLによって終えられたキャラクタの局所的に認識可能なストリング
This command causes the input described by the <input part> to be entered into the RJE job stream and the output produced to be disposed of according to the <output part>. The null condition for either argument implies that the information has been previously specified or is the default.
このコマンドで、<出力パート>に応じて処分されるために製作されたRJEジョブストリームと出力に<入力パート>によって説明された入力を入力します。 議論のためのヌル状態は、情報が以前に指定されたのを含意するか、デフォルトです。
For the <input part>, the <empty> may imply two actions. If an INDEF command has previously specified a <server pathname>, input to the job stream is taken from the file indicated by the file name. If the INDEF command has specified that the input is to come from a CCN-like data transfer socket, the SCHED <empty> command is the signal for the Server to start reading data.
<入力パート>に関しては、<の空の>は2つの動作を含意するかもしれません。 >、INDEFコマンドが以前に<サーバパス名を指定したなら、ジョブストリームへの入力はファイル名によって示されたファイルから抜粋されます。 INDEFコマンドが、入力がCCNのようなデータ転送ソケットから来ることになっていると指定したなら、SCHEDの<の空の>コマンドはServerがデータを読み始める信号です。
The DISCARD modifier, if present, indicates that the file should be discarded after it has been transmitted or it has been received and executed. If the input stream is to be sent on the Telnet connection, the source may be a local device or a human user. This facility is provided for mini-hosts that can't use one of the other techniques and for the user who wishes to enter job control directly at his terminal.
存在しているなら、DISCARD修飾語は、伝えられたか、それが受け取られて、実行された後にファイルが捨てられるべきであるのを示します。 入力ストリームがTelnet接続に送ることであるなら、ソースは、ローカル装置か人間のユーザであるかもしれません。 他のテクニックの1つを使用できないミニホストと直接彼の端末にジョブ制御を入れたがっているユーザにこの施設を提供します。
The empty for output specifies either the primary output file of the job (the default) or a previously specified server pathname (OUTDEF command).
出力のための空は仕事のプライマリ出力ファイル(デフォルト)か以前に指定されたサーバパス名(OUTDEFコマンド)を指定します。
Successful replies to this command should indicate any job-id assigned by the local RJE system along with other status informaton. Failure would be because files did not exist, access was denied, etc.
このコマンドに関するうまくいっている回答は他の状態informatonに伴うローカルのRJEシステムによって割り当てられたどんな仕事イドも示すべきです。 失敗はファイルが存在しなかったのでアクセスが否定されたのなどということでしょう。
OUTPUT <output spec>
OUTPUT<出力仕様>。
<output spec>::= <job-id><xmsn part>|<job-id><server pathname>
<は仕様>を出力しました:、:= <仕事イド><xmsnは離れています。>|<仕事イド><サーバパス名>。
<xmsn part>::= <empty>| /<IO params>
<xmsnパート>:、:= <空です。>| /<IO params>。
<IO params>::= <xmsn params>, <dest>
<IO params>:、:= <xmsn params>、<dest>。
[page 13]
[13ページ]
NWG/RFC# 725 DAY GRG 25-APR-77 12:41 38316 An RJE Protocol for a Resource Sharing Network
NWG/RFC#725のGRG25 4月の77 12日目: リソース・シェアリングネットワークのためのRJEプロトコルあたり41 38316
This command indicates to the Server what output is to be sent to the user, how it is to be sent, and to whom. The <IO params> part will allow the specification of a host and socket so that output may be sent to a TIP printer, or alternatively sent on the Telnet connection or to the default data sockets. This argument also specifies the format and representation of the data.
このコマンドは、どんな出力がそれがユーザ、どう送られることになっているかと、そして、だれに送られるかことであるかをServerに示します。 <IO params>部分は、出力をTIPプリンタに送るか、または代わりにTelnet接続の上、または、デフォルトデータソケットに送ることができるようにホストとソケットの仕様を許容するでしょう。 また、この議論はデータの形式と表現を指定します。
When the Server receives this command, it will proceed to transmit the output to the host in the prescribed manner. The reply structure of this command will depend on how the output is moved and will be discussed in more detail later.
Serverがこのコマンドを受け取るとき、それは処方された方法で出力をホストに伝えかけるでしょう。 このコマンドの回答構造はどう出力について動かされて、さらに詳細に後で議論するかに依存するでしょう。
INPATH
INPATH
This command returns to the user a legal pathname at the Server. The user may then transfer his input to this pathname for eventual submission to the RJE facility.
このコマンドはServerで法的なパス名をユーザに返します。次に、ユーザはRJE施設への最後の服従のために彼の入力をこのパス名に移すかもしれません。
OUTPATH
OUTPATH
This command performs a similar function to INPATH.
このコマンドは同様の機能をINPATHに実行します。
DISCARD <job-file-id> | <server pathname>
<仕事ファイルイド>を捨ててください。| <サーバパス名>。
This allows the user to destroy input or output files associated with a job.
これで、ユーザは仕事に関連している入力か出力ファイルを無効にすることができます。
INDEF <job-id><I/O params>
INDEF<仕事イド><入出力params>。
OUTDEF <job-id><I/O params>
OUTDEF<仕事イド><入出力params>。
These commands allow the user to specify the parameters necessary to send input or retrieve output. This command specifies how the data will be transferred and specifies format, etc.
これらのコマンドで、ユーザは入力を送るか、または出力を検索するのに必要なパラメタを指定できます。 このコマンドは、どうデータを移すかを指定して、形式などを指定します。
CANCEL <job-id>
<仕事イド>を取り消してください。
This command allows a job to be cancelled from the RJE job stream.
このコマンドは、仕事がRJEジョブストリームから中止されるのを許容します。
STATUS <status arg>
STATUS<状態arg>。
status arg ::= <empty>|<user id>|<job-id>|<job-id><blank><job-file-id>
状態は以下をargします:= <空です。>|<ユーザイド>|<仕事イド>|<仕事イド>の<の空白の><仕事ファイルイド>。
This command allows the user to determine the status of the RJE session, all jobs under his usercode, a specific job, or the output of a specific job.
このコマンドで、ユーザはRJEセッションの状態、彼のusercodeの下のすべての仕事、特定の仕事、または特定の仕事の出力を決定できます。
[page 14]
[14ページ]
NWG/RFC# 725 DAY GRG 25-APR-77 12:41 38316 An RJE Protocol for a Resource Sharing Network
NWG/RFC#725のGRG25 4月の77 12日目: リソース・シェアリングネットワークのためのRJEプロトコルあたり41 38316
ALTER <job-id><site specific option>
ALTER<仕事イド>の<のサイトの特定のオプション>。
SITE <site specific option>
SITEの<のサイトの特定のオプション>。
These commands allow site specific commands to be passed to the Server RJE system. The ALTER command is intended to effect specific jobs, while the SITE command is used for commands of more global effect. They could be merged into one.
これらのコマンドはServer RJEシステムに通過するべきサイト特定のコマンドを許容します。 ALTERコマンドが特定の仕事に作用することを意図します、SITEコマンドは、よりグローバルな効果のコマンドに使用されますが。 それらを1つに合併できました。
OP <operator message>
OP<オペレータメッセージ>。
This command allows messages to be sent to the operator at the Server site.
このコマンドはServerサイトのオペレータに送られるべきメッセージを許容します。
Reply Codes for the Proposed NETRJE -----------------------------------
提案されたNETRJEのための回答コード-----------------------------------
The reply codes for this protocol will follow the model proposed for the new FTP specificaton in RFC 640. As a reminder we insert the pertinent information from that RFC:
このプロトコルのための回答コードはRFC640の新しいFTP specificatonのために提案されたモデルに従うでしょう。 思い出させるものとして、私たちはそのRFCから適切な情報を挿入します:
There are five values for the first digit of the reply code:
回答コードの最初のケタのための5つの値があります:
1yz Positive Preliminary reply
1yz Positive Preliminary回答
The requested action is being initiated; expect another reply before proceeding with a new command. (The user-process sending another command before the completion reply would be in violation of protocol; but server-FTP processes should queue any commands that arrive while a preceding command is in progress.) For implementations where simultaneous monitoring is difficult, this type of reply can be used to indicate that the command was accepted and the user-process may now pay attention to the data connections.
要求された動作は開始されています。 新しいコマンドを続ける前に、別の回答を予想してください。 (完成回答の前に別のコマンドを送るユーザ・プロセスはプロトコルを違反しているでしょう; しかし、サーバFTPプロセスは前のコマンドが進行している間に到着するどんなコマンドも列に並ばせるはずです。) 実装において、同時のモニターが難しいところでユーザ・プロセスがコマンドを受け入れて、現在注意を向けるかもしれないのをデータ接続に示すのにこのタイプの回答を使用できます。
2yz Positive Completion reply
2yz Positive Completion回答
The requested action has been successfully completed. A new request may be initiated.
要求された操作は首尾よく完了しました。 新しい要求は開始されるかもしれません。
3yz Positive Intermediate reply
3yz Positive Intermediate回答
The command has been accepted, but the requested action is being held in abeyance, pending receipt of further information. The user should send another command specifying this information. This reply is used in command sequence groups.
コマンドを受け入れましたが、詳細の領収書まで停止しているのに要求された動作を保っています。 ユーザは別のコマンドにこの情報を指定させるべきです。 この回答はコマンド・シーケンスグループに使用されます。
[page 15]
[15ページ]
NWG/RFC# 725 DAY GRG 25-APR-77 12:41 38316 An RJE Protocol for a Resource Sharing Network
NWG/RFC#725のGRG25 4月の77 12日目: リソース・シェアリングネットワークのためのRJEプロトコルあたり41 38316
4yz Transient Negative Completion reply
4yz Transient Negative Completion回答
The command was not accepted and the requested action did not take place, but the error condition is temporary and the action may be requested again. The user should return to the beginning of the command sequence, if any. It is difficult to assign a meaning to "transient", particularly when two distinct sites (Server and User-processes) have to agree on the interpretation. Each reply in the 4yz category might have a slightly different time value, but the intent is that the user-process is encouraged to try again. A rule of thumb in determining if a reply fits into the 4yz or the 5yz (Permanent Negative) category is that replies are 4yz if the commands can be repeated without any change in command form or in properties of the User or Server (e.g., the command is spelled the same with the same arguments used, the user does not change his file access or user name, the server does not put up a new implementation.)
コマンドは受け入れられませんでした、そして、エラー条件は一時的です、そして、要求された動作は行われませんでしたが、動作は再び要求されているかもしれません。 ユーザはコマンド・シーケンスの始まりまでもしあれば戻るべきです。 「一時的に」意味を割り当てるのは難しいです、特に2つの異なったサイト(サーバとUser-プロセス)が解釈に同意しなければならないとき。 4yzカテゴリにおける各回答には、わずかに異なった時間的価値があるかもしれませんが、意図はユーザ・プロセスが再試行するよう奨励されるということです。 UserかServerでコマンドフォームか所有地の回答が4yzに収まるか、5yz(永久的なNegative)カテゴリが少しも変化なしでコマンドを繰り返すことができるなら回答が4yzであるということであるかを決定することにおける経験則(同じ議論が使用されている状態で、例えばコマンドは同じようにつづられて、ユーザは彼のファイルアクセスかユーザ名を変えないで、またサーバは新しい実装を提供しません。)
5yz Permanent Negative Completion reply
5yz Permanent Negative Completion回答
The command was not accepted and the requested action did not take place. The User-process is discouraged from repeating the exact request (in the same sequence). Even some "permanent" error conditions can be corrected, so the human user may want to direct his User-process to reinitiate the command sequence by direct action at some point in the future (e.g., after the spelling has been changed, or the user has altered his directory status.)
コマンドは受け入れられませんでした、そして、要求された動作は行われませんでした。 User-プロセスは、正確な要求(同じ系列の)を繰り返して、がっかりしています。 人間のユーザは、いくつかの「永久的な」エラー条件さえ修正できるので、いくつかの直接行動によるコマンド・シーケンスが将来指す再開始に彼のUser-プロセスを向けたがっているかもしれません。(例えば、スペルを変えたか、またはユーザが彼のディレクトリ状態を変更した後に。)
The following function groupings are encoded in the second digit:
以下の機能組分けは2番目のケタでコード化されます:
x0z Syntax - These replies refer to syntax errors, syntactically correct commands that don't fit any functional category, and unimplemented or superfluous commands.
x0z構文--これらの回答は構文エラー、どんな機能的なカテゴリにも合わないシンタクス上正しいコマンド、および非実装しているか余計なコマンドを示します。
x1z Information - These are replies to requests for information, such as status or help.
x1z情報--これらは、状態などの情報に関する要求に関する回答であるか助けます。
x2z Connection - Replies referring to the Telnet and data connections.
x2z接続--Telnetについて言及する回答とデータ接続。
x3z Authentication and accounting - Replies for the logon process and accountng procedures.
x3z認証と会計--ログオンプロセスとaccountng手順のための回答。
x4z Unspecified as yet.
まだ不特定のx4z。
x5z File system - These replies indicate the status of the Server file system vis-a-vis the requested transfer or other file system action.
x5zファイルシステム--これらの回答は要求された転送か他のファイルシステム動作と向かいあってServerファイルシステムの状態を示します。
[page 16]
[16ページ]
NWG/RFC# 725 DAY GRG 25-APR-77 12:41 38316 An RJE Protocol for a Resource Sharing Network
NWG/RFC#725のGRG25 4月の77 12日目: リソース・シェアリングネットワークのためのRJEプロトコルあたり41 38316
The third digit gives a finer gradation of meaning in each of the function categories specified by the second digit. The list of replies below will illustrate this. Note that the text associated with each reply is suggestive, rather than mandatory, and may even change according to the command with which it is associated. The reply codes, on the other hand, should strictly follow the specifications. That is, Server implementations should not invent new codes for situations that are only slightly different from the ones described here, but rather should adapt codes already defined.
3番目のケタは2番目のケタによって指定されたそれぞれの機能カテゴリにおける意味の、よりすばらしい段階を与えます。 以下での回答のリストはこれを例証するでしょう。 各回答に関連しているテキストが義務的であるというよりむしろ思わせ振りであり、それが関連しているコマンドに応じて変化さえするかもしれないことに注意してください。 他方では、回答コードは厳密に仕様に従うべきです。 すなわち、Server実装は、ここで説明されたものとわずかにだけ異なった状況のための新法を発明するべきではありませんが、むしろ既に定義されたコードを適合させるべきです。
Below is a list of replies ordered by reply code. Some new replies have been added for RJE; these are marked by asterisks to aid the reader. Following this list is a list of commands with the replies that are possible for that command. This list is not considered complete or final; as usual comments are welcomed.
以下に、回答コードによって注文された回答のリストがあります。 いくつかの新しい回答がRJEのために加えられます。 これらはアスタリスクによってマークされて、読者を支援します。 このリストに従うのは、そのコマンドに、可能な回答によるコマンドのリストです。 このリストは完全であるか、または最終的であると考えられません。 いつものように、コメントは歓迎されます。
110 Restart marker reply,
110はマーカー回答を再開します。
In this case the text is exact and not left to the particular implementation; it must read:
この場合、テキストは、正確であり、特定の実装に出られません。 それは読まなければなりません:
MARK yyyy = mmmm
マークyyyyはmmmmと等しいです。
where yyyy is user-process data stream marker, and mmmm is Server's equivalent marker. (Note the spaces between the markers and "=".)
yyyyがユーザ・プロセスであるところでは、データはマーカーを流します、そして、mmmmはServerの同等なマーカーです。 (マーカーと「=」の間の空間に注意してください。)
120 Service ready in nnn minutes
120 nnn分で準備ができるサービス
125 Data connection already open; transfer starting
125 データ接続は既に開きます。 転送始め
150 File status okay; about to open data connection
150 間違いなく状態をファイルしてください。 データ接続を開こうとしているために
200 Command okay
200コマンド承認
202 Command not implemented, superfluous at this site
202 このサイトで実装していて、余計でないコマンド
211 System status, or system help reply
211のシステム状態、またはシステム助け回答
212 Directory status
212 ディレクトリ状態
213 File status
213 ファイル状態
214 Help message (on how to use the server or the meaning of a particular non-standard command. This reply is useful only to the human user.)
214ヘルプメッセージ(どう特定の標準的でないコマンドのサーバか意味を使用するかに関して。 この回答は人間のユーザだけの役に立ちます。)
*215 RJE general status reply
*215 RJEの一般的な状態回答
[page 17]
[17ページ]
NWG/RFC# 725 DAY GRG 25-APR-77 12:41 38316 An RJE Protocol for a Resource Sharing Network
NWG/RFC#725のGRG25 4月の77 12日目: リソース・シェアリングネットワークのためのRJEプロトコルあたり41 38316
*216 job status reply
*216 地位の回答
*217 RJE user's jobs status reply
*217 RJEユーザの仕事の状態回答
220 Service ready for new user
220 新しいユーザの準備ができるサービス
221 Service closing TELNET connecton (logged off if appropriate)
221 TELNET connectonを閉じるサービス(オフですが、適切な状態で、登録されます)
225 Data connection open; no transfer in progress
接続開いている225のデータ。 進行中の転送がありません。
226 Closing data connection; requested file action successful (for example, file transfer or file abort.)
226 終わりのデータ接続。 要求されたファイル動作うまくいきます。(例えば、ファイル転送かファイルアボート。)
227 Entering [passive, active] mode
227 入る[受け身の、そして、アクティブな]モード
230 User logged in
ログインされた230ユーザ
250 Requested file action okay, completed
完成されて、250は間違いなくファイル動作を要求しました。
*260 Job <job-id> has completed
*260 >が完成した仕事の<仕事イド
*261 Output ready. Type an empty line when ready
*261 準備ができていた状態で、出力されます。 準備ができているときには空の系列をタイプしてください。
*262 Job <job-id> IS ALLOCATED pathname
*262 仕事の<の賃仕事のイドの>IS ALLOCATEDパス名
*263 Job <job-id> cancelled as requested
*263 要求された通り取り消された仕事の<仕事イド>。
*264 Job <job-id> altered as requested to state status
*264 状態を述べるために要求された通り変更された仕事の<仕事イド>。
331 User name okay, need password
331ユーザ名前承認、必要性パスワード
332 Need account for login
ログインのための332必要性アカウント
350 Requested file action held in abeyance, pending further information
350 詳細まで停止しているのに保たれた要求されたファイル動作
354 Start mail input; end with CRLF, CRLF
354 メール入力を始めてください。 CRLF、CRLFと共に終わってください。
*360 Job <job-id> successfully submitted
*360 首尾よく提出された仕事の<仕事イド>。
421 Service not available, closing Telnet connecton. (This may be a reply to any command if the service knows it must shut down.)
421はどんな利用可能で、終わりのTelnet connectonも調整しません。 (サービスが、それが停止しなければならないのを知っているなら、これはどんなコマンドに関する回答であるかもしれません。)
425 Can't open data connection
425はデータ接続を開くことができません。
426 Connection trouble, closed; transfer aborted
426 接続問題であって、閉じられる。 転送は中止になりました。
[page 18]
[18ページ]
NWG/RFC# 725 DAY GRG 25-APR-77 12:41 38316 An RJE Protocol for a Resource Sharing Network
NWG/RFC#725のGRG25 4月の77 12日目: リソース・シェアリングネットワークのためのRJEプロトコルあたり41 38316
450 Requested file action not taken; file unavailable (e.g., file not found, no access)
450は取られなかったファイル行動を要求しました。 入手できないファイル(例えば、ファイルが見つからない、アクセスがありません)
451 Requested action aborted; local error in processing
451は、動作が中止になったよう要求しました。 処理における地方の誤り
452 Requested action not taken: insufficient storage space in system
452は取られなかった行動を要求しました: システムの不十分な集積スペース
500 Syntax error, command unrecognized (This may include errors such as command line too long.)
500構文エラーで、コマンド認識されていません。(これはあまりに長い間、コマンドラインなどの誤りを含むかもしれません。)
501 Syntax error in parameters or arguments
パラメタか議論における501構文エラー
502 Command not implemented
コマンドが実装しなかった502
503 Bad sequence of commands
503 コマンドの悪い系列
504 Command not implemented for that parameter
504 そのパラメタのために実装されなかったコマンド
530 Not logged in
530はログインされませんでした。
532 Need account for storing files
ファイルを保管するための532必要性アカウント
550 Requested action not taken: file unavailable (e.g., file busy)
550は取られなかった行動を要求しました: 入手できないファイル(例えば、忙しい状態で、ファイルします)
552 Requested file action aborted: exceeded storage allocation for current directory or dataset)
552は、ファイル動作が中止になったよう要求しました: カレントディレクトリかデータセットのための超えられている記憶領域の割当て)
553 Requested action not taken: file name not allowed
553は取られなかった行動を要求しました: 許容されなかったファイル名
*563 Job <job-id> is not known to the system
*563 仕事の<仕事イド>はシステムに知られていません。
*564 Requested alteration is not permitted for the specified job.
*564 要求された変更は指定された仕事のために受入れられません。
Reply codes for RJE
RJEのための回答コード
USER
ユーザ
230
230
530
530
500, 501, 421
500, 501, 421
331, 332
331, 332
PASS
パス
[page 19]
[19ページ]
NWG/RFC# 725 DAY GRG 25-APR-77 12:41 38316 An RJE Protocol for a Resource Sharing Network
NWG/RFC#725のGRG25 4月の77 12日目: リソース・シェアリングネットワークのためのRJEプロトコルあたり41 38316
230
230
202
202
530
530
500, 501, 503, 421
500, 501, 503, 421
332
332
ACCT
ACCT
230
230
202
202
530
530
500, 501, 503, 421
500, 501, 503, 421
BYE
さようなら
221
221
500
500
REINIT
REINIT
120
120
220
220
220
220
421
421
500, 502
500, 502
ABORT
アボート
225, 226
225, 226
500, 501, 502, 421
500, 501, 502, 421
STATUS
状態
211, 212, 213
211, 212, 213
[page 20]
[20ページ]
NWG/RFC# 725 DAY GRG 25-APR-77 12:41 38316 An RJE Protocol for a Resource Sharing Network
NWG/RFC#725のGRG25 4月の77 12日目: リソース・シェアリングネットワークのためのRJEプロトコルあたり41 38316
450
450
500, 501, 502, 421, 530
500, 501, 502, 421, 530
HELP
ヘルプ
211, 214
211, 214
500, 501, 502, 421
500, 501, 502, 421
SOCK
ソックス
200
200
500, 501, 421, 530
500, 501, 421, 530
BYTE, MODE, TYPE, STRU
バイト、モード、タイプ、STRU
200
200
500, 501, 504, 421, 530
500, 501, 504, 421, 530
SCHED
SCHED
360 JOB <job-id> successfully submitted
首尾よく提出された360JOB<仕事イド>。
260 Job <job-id> has completed.
>が完成した260仕事の<仕事イド。
125 500
125 500
425, 426 501
425, 426 501
226 504, 532
226 504, 532
OUTPUT
出力
261 Output ready. Type an empty line when ready.
261 準備ができていた状態で、出力されます。 準備ができているときには空の系列をタイプしてください。
125 Transfer started
125 転送は始まりました。
226 500
226 500
425, 426 501
425, 426 501
110
110
OUTDEF
OUTDEF
[page 21]
[21ページ]
NWG/RFC# 725 DAY GRG 25-APR-77 12:41 38316 An RJE Protocol for a Resource Sharing Network
NWG/RFC#725のGRG25 4月の77 12日目: リソース・シェアリングネットワークのためのRJEプロトコルあたり41 38316
225 Data connection opened, no transfer in progress.
接続が開いた225のデータ、進行中の転送がありません。
425 500
425 500
501
501
504
504
INDEF
INDEF
225 500
225 500
425 501
425 501
504
504
INPATH/OUTPATH
INPATH/OUTPATH
262 JOB <job-id> IS ALLOCATED PATHNAME >
262仕事の<仕事イド>にパス名>を割り当てます。
500 504
500 504
501
501
DISCARD
破棄
250 500 530
250 500 530
450 501
450 501
550 502
550 502
421
421
CANCEL
キャンセル
263 Job <job-id> Cancelled as requested
263仕事の<仕事イド>Cancelled、要求された通り。
500 504
500 504
501
501
502
502
563 Job <job-id> is not known to the system
563仕事の<仕事イド>はシステムに知られていません。
[page 22]
[22ページ]
NWG/RFC# 725 DAY GRG 25-APR-77 12:41 38316 An RJE Protocol for a Resource Sharing Network
NWG/RFC#725のGRG25 4月の77 12日目: リソース・シェアリングネットワークのためのRJEプロトコルあたり41 38316
564 Requested Alteration is not permitted for the specific
job.
564 要求されたAlterationは特定の仕事のために受入れられません。
STATUS
状態
215 RJE general status reply
215のRJEの一般的な状態回答
216 RJE job status reply
216RJE地位の回答
217 RJE user's jobs status reply
217RJEユーザの仕事の状態回答
500, 501, 502, 504
500, 501, 502, 504
ALTER
変わってください。
264 Job <job-id> altered as requested to state status
状態を述べるために要求された通り変更された264仕事の<仕事イド>。
500, 501, 502, 504 563, 564
500, 501, 502, 504 563, 564
SITE
サイト
200
200
500, 501, 502, 504
500, 501, 502, 504
OP
オプアート
200
200
500, 501, 502, 504
500, 501, 502, 504
[page 23]
[23ページ]
NWG/RFC# 725 DAY GRG 25-APR-77 12:41 38316 An RJE Protocol for a Resource Sharing Network
NWG/RFC#725のGRG25 4月の77 12日目: リソース・シェアリングネットワークのためのRJEプロトコルあたり41 38316
References ----------
参照----------
Braden, R.
ブレーデン、R。
1971 "Interim NETRJS Specifications", RFC 189, NIC 7133.
1971「当座のNETRJS仕様」、RFC189、NIC7133。
Bressler, R.; Guida, R.; and McKenzie, A.
Bressler、R.。 Guida、R.。 マッケンジー、A。
1972 "Remote Job Entry Protocol", RFC 407
1972「リモートジョブエントリプロトコル」、RFC407
Neigus, N.
Neigus、N。
1973 "The File Transfer Protocol", RFC 542.
1973 「ファイル転送プロトコル」、RFC542。
Neigus, N.; Pogran, K.; and Postel, J.
Neigus、N.。 Pogran、K.。 ポステル、J。
1974 "A New Schema for FTP Reply Codes", RFC 640.
1974 「FTP回答コードのための新しい図式」、RFC640。
[page 24]
[24ページ]
NWG/RFC# 725 DAY GRG 25-APR-77 12:41 38316 An RJE Protocol for a Resource Sharing Network
NWG/RFC#725のGRG25 4月の77 12日目: リソース・シェアリングネットワークのためのRJEプロトコルあたり41 38316
Figures -------
図-------
+-----------+
! !
! user !
! RJE !
! interface !
! !
+-----------+ +--------+ Telnet Connection +--------+
! ! ! ! !
! ! user !------------------------->! server !
------------! RJE ! ! RJE !
! module !<-------------------------! module !
! ! ! !
+--------+ +--------+
+-----------+! ユーザ!RJE!インタフェース!+-----------+ +--------+ telnet接続+--------+! ユーザ!------------------------->! サーバ!------------! RJE!RJE!モジュール!<。-------------------------! モジュール!+--------+ +--------+
all RJE commands, replies and data on telnet connection
telnet接続に関するすべてのRJEコマンド、回答、およびデータ
RJE Using Only Telnet
telnetだけを使用するRJE
Figure 1.
図1。
+-----------+
! user !
! RJE !
! interface !
+-----------+ +--------+ Telnet Connection +--------+
! ! user !--------------------------->! server !
------------! RJE ! RJE Commands and Replies ! RJE !
! module !<---------------------------! module !
+--------+ +--------+
! !
+--------+ +--------+
! data ! RJE Data ! data !
!transfer!----------------------------!transfer!
+--------+ +--------+
! !
User's Local File System Server's RJE System
Card Readers or Line Printers
+-----------+ RJE!インタフェース!ユーザ!+-----------+ +--------+ telnet接続+--------+! ユーザ!--------------------------->! サーバ!------------! RJE!RJE CommandsとReplies!RJE!モジュール!<。---------------------------! モジュール!+--------+ +--------+ ! ! +--------+ +--------+! データ!RJE Data!データ!移してください!----------------------------移してください! +--------+ +--------+! ユーザのローカルファイルシステムサーバのRJEシステムカードリーダかラインプリンタ
RJE Using a Separate Data Connection
別々のデータ接続を使用するRJE
Figure 2.
図2。
[page 25]
[25ページ]
NWG/RFC# 725 DAY GRG 25-APR-77 12:41 38316 An RJE Protocol for a Resource Sharing Network
NWG/RFC#725のGRG25 4月の77 12日目: リソース・シェアリングネットワークのためのRJEプロトコルあたり41 38316
+-----------+
! user !
! RJE !
! interface !
+-----------+ +--------+ Telnet Connection +--------+
! ! user !--------------------------->! server !
------------! RJE ! RJE Commands and Replies ! RJE !
! module !<---------------------------! module !
+--------+ +--------+
+-----------+ RJE!インタフェース!ユーザ!+-----------+ +--------+ telnet接続+--------+! ユーザ!--------------------------->! サーバ!------------! RJE!RJE CommandsとReplies!RJE!モジュール!<。---------------------------! モジュール!+--------+ +--------+
! !
+--------+ Telnet Connection +--------+
! user !--------------------------->! server !
! FTP ! FTP Commands and Replies ! FTP !
! module !<---------------------------! module !
+--------+ +--------+
! ! +--------+ telnet接続+--------+ ユーザ!--------------------------->! サーバ!FTP!FTP CommandsとReplies!モジュール!FTP!<。---------------------------! モジュール!+--------+ +--------+
! !
+--------+ +--------+
! data ! RJE Data ! data !
!transfer!----------------------------!transfer!
+--------+ +--------+
! !
User's Local File System Server's File
System
Card Readers or Line Printers
! ! +--------+ +--------+! データ!RJE Data!データ!移してください!----------------------------移してください! +--------+ +--------+! ユーザのローカルファイルシステムサーバのファイルシステムカードリーダかラインプリンタ
RJE Using FTP
FTPを使用するRJE
Figure 3.
図3。
[page 26]
[page 26]
一覧
スポンサーリンク
