RFC368 日本語訳
0368 Comments on "Proposed Remote Job Entry Protocol". R.T. Braden. July 1972. (Format: TXT=3883 bytes) (Status: UNKNOWN)
プログラムでの自動翻訳です。
英語原文
Network Working Group R.T. Braden Request for Comments #368 UCLA/CCN NIC 11015 July 21, 1972 Categories: Obsoletes: Updates:
コメント#368UCLA/CCN NIC11015 1972年7月21日カテゴリを求めるワーキンググループR.T.ブレーデン要求をネットワークでつないでください: 時代遅れにします: アップデート:
COMMENTS ON "PROPOSED REMOTE JOB ENTRY PROTOCOL"
「提案されたリモートジョブエントリプロトコル」のコメント
Chuck Holland's draft proposal (RFC #360) is an excellent document, very complete and consistent. Since the final standard RJE protocol will be widely used on the Network, honing its definition now will save trouble and discontent later. Therefore, I will proceed to make a new suggestions and pick a few nits.
チャック・オランダの試案(RFC#360)は非常に完全で一貫した素晴らしいドキュメントです。 最終的な標準のRJEプロトコルがNetworkで広く使用されるので、現在定義を磨くと、手間と不満は後で省かれるでしょう。 したがって、私は、新たな提案して、数人の夜を選びかけるでしょう。
1. In my humble opinion, the command verb "BYE" is overly cute; I would find "QUIT" much less offensive
1. 私見によれば、「さようなら」というコマンド動詞はひどくかわいいです。 私は、「やめてください」があまりそれほど不快でないことがわかったでしょう。
2. The "(pathname)" syntax (p.5) may need some reworking. It would be very desirable for all protocols or Network access programs to use the same syntax for selecting a host and socket and/or file name. (Note that the FTP documents use the term "pathname" in the more restricted sense of a local file system name.)
2. 「(パス名)」構文(p.5)はいくつかの作りなおすことを必要とするかもしれません。 すべてのプロトコルかNetworkアクセスプログラムがホストとソケット、そして/または、ファイル名を選ぶのに同じ構文を使用するのは、非常に望ましいでしょう。 (FTPドキュメントがローカルファイルシステム名のさらに制限された意味で「パス名」という用語を使用することに注意してください。)
a. The PORT construction seems very undesirable, since it depends upon a particular bit convention of TIP's. TIP's have bent Network protocols rather badly in the past, but surely we don't want to build their particular socket system into an official protocol.
a。 PORT工事は、TIPの特定の噛み付いているコンベンションによるので、全く望ましくなく思えます。 TIPは過去にかなりひどくNetworkプロトコルを曲げましたが、確実に、それらの特定のソケットシステムを公式のプロトコルに組み込みたいと思いません。
b. For convenience, it may be desirable to allow hex and octal socket numbers.
b。 便利に、十六進法と8進ソケット番号を許容するのは望ましいかもしれません。
c. There will probably be other hosts besides TIP's which will use the "(host-socket)" pathname, and some of them may want a transmission attribute other than "T". The proposed syntax should be changed to allow (attributes) in (host-socket)
c。 他のホストが「(ホストソケット)」パス名を使用するTIPのもの以外にたぶんいるでしょう、そして、彼らの何人かが「T」を除いたトランスミッション属性が欲しいかもしれません。 構文が(属性)を許容するために変わるべきである提案(ホストソケット)
d. I see no reason to exclude attribute "TE", since the control characters cr, lf, and ff exist in EBCDIC as well as ASCII.
d。 私は属性「Te」を除く理由が全くわかりません、制御文字cr、lf、およびffがASCIIと同様にEBCDICに存在しているので。
e. There are many EBCDIC codes, and at least 2 ASCII's. The (code) construction needs expansion.
e。 多くのEBCDICコード、および少なくとも2アスキーのものがあります。 (コード)工事は拡張を必要とします。
[Page 1] 3. The syntax of OUT might reflect the fact that pathname is required only for (disp) of "(S)".
[1ページ] 3。 OUTの構文はパス名が"(S)"の(disp)にだけ必要であるという事実を反映するかもしれません。
4. It may be desirable to distinguish syntactically (job-id) and job-file-id). For example, this would allow the command
4. シンタクス上(仕事イド)と仕事のファイルイドを区別するのが望ましいかもしれない、) 例えば、これはコマンドを許容するでしょう。
ABORT (job-file-id)
アボート(仕事のファイルイド)
to abort the job currently being transmitted, regardless of its id (this assumes that multiple jobs for a given user are sent sequentially).
現在イド(これは、与えられたユーザのための複数の仕事が連続して送られると仮定する)にかかわらず伝えられる仕事を中止するために。
5. The replies presented in the document are very good, but may need some elaboration. For example, the syntax error messages should be more specific. When the user enters:
5. ドキュメントに示された回答は、非常に良いのですが、いくらかの労作を必要とするかもしれません。 例えば、構文エラーメッセージは、より特定であるべきです。 ユーザが入ると:
OUT=(H) UCLA91: NE/ARP998.WGW.TEST
出ている=(H)UCLA91: Ne/ARP998.WGW.TEST
he would like the error message to indicate explicitly that the hostname is not valid, rather than merely being told there is something wrong with one of the parameters.
彼は、エラーメッセージに、パラメタの1つには不具合があると単に言われるよりホスト名がむしろ有効でないことを明らかに示して欲しいです。
6. Experience with remote job entry to CCN via the Network has shown that the user wants a transmission status command, to find out how many records have been sent or received so far. The network bandwidth corresponds in order of magnitude to one page per second. The average output for jobs submitted to CCN from the Network has contained about 30 pages, so significant transmission delays are not unusual. It is important to add a command for this purpose.
6. Networkを通したCCNへのリモートジョブエントリの経験は、ユーザが今までのところいくつの記録を送るか、または受け取ったかを見つけるために送信状況コマンドが欲しいのを示しました。 ネットワーク回線容量は1秒あたり1ページまでの大きさの順に対応しています。 NetworkからCCNに提出された仕事のための平均した出力はおよそ30ページを含みました、非常に重要であるので、トランスミッション遅れは珍しくはありません。 このためにコマンドを加えるのは重要です。
[ This RFC was put into machine readable form for entry ] [ into the online RFC archives by BBN Corp. under the ] [ direction of Alex McKenzie. 1/97 ]
[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした]、[BBN社の下によるオンラインRFCアーカイブ、][ アレックス・マッケンジーの方向。 1/97 ]
[Page 2]
[2ページ]
一覧
スポンサーリンク