RFC1440 日本語訳
1440 SIFT/UFT: Sender-Initiated/Unsolicited File Transfer. R. Troth. July 1993. (Format: TXT=17366 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group R. Troth Request for Comments: 1440 Rice University July 1993
コメントを求めるワーキンググループR.信実要求をネットワークでつないでください: 1440 ライス大学1993年7月
SIFT/UFT: Sender-Initiated/Unsolicited File Transfer
/UFTをふるいわけてください: 送付者によって開始されたか求められていないファイル転送
Status of this Memo
このMemoの状態
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard. Discussion and suggestions for improvement are requested. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 それはインターネット標準を指定しません。 議論と改善提案は要求されています。 このプロトコルの標準化状態と状態の「IABの公式のプロトコル標準」の現行版を参照してください。 このメモの分配は無制限です。
1. Introduction
1. 序論
This document describes a Sender-Initiated File Transfer (SIFT) protocol, also commonly called Unsolicited File Transfer (UFT) protocol. The acronyms SIFT and UFT are synonymous throughout this document. The term "unsolicited" does not imply that the file is unwanted, but that the receiver did not initiate the transaction.
このドキュメントはSenderによって開始されたFile Transfer(SIFT)プロトコルについて説明します、また、一般的に呼ばれたUnsolicited File Transfer(UFT)は議定書を作ります。 頭文字語のSIFTとUFTはこのドキュメント中で同義です。 「求められていません」という用語は、ファイルが求められていないのですが、受信機がトランザクションを開始しなかったのを含意しません。
Sender-Initiated File Transfer contrasts with other file transfer methods in that the sender need not have an account or any registration on the target host system, and the receiving user may have less steps to take to retrieve the file(s) sent. Unlike traditional file transfer, UFT lends itself handily to background or deferred operation, though it may be carried out immediately, even interactively.
送付者が目標ホストシステムの上にアカウントか少しの登録も持つ必要はないので、送付者によって開始されたFile Transferは他のファイル転送メソッドを対照をなします、そして、受信ユーザには、(s)が送ったファイルを取るために採るより少ない方法があるかもしれません。 伝統的なファイル転送と異なって、UFTはバックグラウンドか延期された操作にそれ自体を手際よく与えます、それがすぐに、インタラクティブにさえ行われるかもしれませんが。
2. Rationale
2. 原理
In certain non-IP networks, notably NJE based networks such as BITNET, it is possible to send a file to another user outside of the realm of "mail". The effect is that the file sent is not perceived as correspondence and not processed by a mail user agent. This convenient service is missed in the standard TCP/IP suite. The author maintains that traditional electronic mail is not suited to non-correspondence file transfer. There should be a means of sending non-mail, analogous to the sending of parcels rather than surface mail. Several groups and individuals have shown an interest in this type of service.
ある非IPネットワークでは、著しくNJEはBitnetなどのネットワークを基礎づけて、「メール」の分野の外で別のユーザにファイルを送るのは可能です。 効果は送られたファイルが通信として知覚されないで、またメールユーザエージェントによって処理されないということです。 この便利なサービスは標準のTCP/IPスイートで逃されています。 作者は、伝統的な電子メールが非通信ファイル転送に合っていないと主張します。 船便よりむしろ小包の発信への非メールの、そして、類似の発信の手段があるべきです。 いくつかのグループと個人はこのタイプのサービスへの関心を示しました。
Troth [Page 1] RFC 1440 SIFT/UFT July 1993
信実[1ページ]RFC1440はUFT1993年7月に/をふるいわけます。
3. Specification
3. 仕様
We define sender-initiated file transfer for IP as a TCP service as follows: a receiver program (the server or "daemon") listens on port 608 for inbound connections. Client programs connect to this port and send a sequence of commands followed by a stream of data. The entire job stream may be thought of as the concatenation of two files, 1) a control file, and 2) a data file, where the control file is plain text and the data file may be any of several formats, but is stored and sent as binary. After each command, the receiver either ACKs (signals positive acknowledgement) or NAKs (signals negative acknowledgement). The target host may reject a file for various reasons, most obvious being 1) that there is no local user matching the intended user, or 2) that there is not enough space to hold the incoming file.
私たちはIPのために送付者によって開始されたファイル転送を以下のTCPサービスと定義します: 受信機プログラム(サーバか「デーモン」)は本国行きの接続のためにポート608の上で聴かれます。 クライアントプログラムは、このポートに接続して、データのストリームがあとに続いたコマンドの系列を送ります。 仕事全体ストリームが2個のファイルの連結、制御ファイルあたり1、)および1データファイルあたり2として)考えられるかもしれなくて、バイナリーとしてデータファイルをいくつかの形式のどれかであるかもしれませんが、保存して、送ります。(そこでは、制御ファイルがプレーンテキストです)。 各コマンド(受信機のACKs(積極的な承認に合図する)かNAKs(否定的承認に合図する)のどちらか)の後に。 目標ホストは様々な理由でファイルを拒絶するかもしれません、いいえ、ある1であることの)対象とする使用者に合っている地元のユーザか入来を保持できるくらいのスペースではなく、ある2が)ファイルされるのが最も明白です。
Most UFT commands are parametric. That is, they don't necessarily invoke an action as much as change parameters of the one action, transfer of the file(s) being sent. This means that UFT is suitable for encapsulation in some higher-level "envelope", such as mail. However, the obvious prefered medium for UFT is TCP.
ほとんどのUFTコマンドがパラメトリックです。 すなわち、彼らは必ず1つの動作(送られるファイルの転送)の変化パラメタと動作を同じくらい呼び出すというわけではありません。 これは、UFTがメールなどの、よりハイレベルのいくつかの「封筒」のカプセル化に適していることを意味します。 しかしながら、UFTのための明白なprefered媒体はTCPです。
When files arrive at the destination host, they are kept in a public area, say /usr/spool/uft, until accepted or rejected by the recipient user or discarded for age by the system. This staging area is public in the sense of shared space, not unrestricted access. Exactly how long files may remain unprocessed and exactly how large these transient files may be is a local administrative or implementation decision.
ファイルがあて先ホストに届くとき、それらは公共区域に保たれます、と/usr/spool/uftは言います、システムで受け入れるか、受取人ユーザが拒絶するか、または期間、捨てるまで。 この中間準備地域は無制限なアクセサリーではなく、共有されたスペースの意味で公共です。 まさに、ファイルがどれくらい長い間そうするかもしれないかは未加工のままで残っています、そして、これらの一時的なファイルがまさにどれくらい大きいかもしれないかは、管理か実装のローカルの決定です。
But not all hosts have IP connectivity; not all hosts will want to put up yet another server; not all hosts will be on the unrestricted side of a "fire wall" that only passes mail. In such cases, UFT may be transported via MIME (Multipurpose Internet Mail Extensions) as Content-Type: application/octet-stream. UFT commands then become parameters to the Content-Type field and the data file is carried as the mail body. While the data file is carried in raw (binary) form over TCP, it is encoded in BASE64 when carried by mail.
しかし、すべてのホストには、IPの接続性があるというわけではありません。 すべてのホストがさらに別のサーバを提供したくなるというわけではないでしょう。 すべてのホストがメールを通過するだけである「ファイアウォール」無制限側にいるというわけではないでしょう。 そのような場合、コンテントタイプとしてのMIME(マルチパーパスインターネットメールエクステンション)でUFTは輸送されるかもしれません: 八重奏アプリケーション/ストリーム。 次に、UFTコマンドはコンテントタイプ分野へのパラメタになります、そして、データファイルはメール本文として運ばれます。 データファイルは生(2進の)のフォームでTCPの上まで運ばれますが、メールによって運ばれると、それはBASE64でコード化されます。
UFT supports several representation types. The receiving host should accept any file type sent. If the representation type is not meaningful to the target host system, then it should be treated as "binary" (image). The data file (body) should be processed as little as possible until the target user (recipient) acts to accept (receive) it. The commands from the client may be stored in the form of a plain-text file so that processing otherwise foreign to the receiver may be off-loaded from the TCP listener. So there are actually two files: the command sequence and the file body.
UFTはいくつかの表現タイプをサポートします。 受信ホストはタイプが送ったどんなファイルも受け入れるべきです。 表現タイプが目標ホストシステムに重要でないなら、それは「バイナリー」(イメージ)として扱われるべきです。 利用対象者(受取人)がそれを受け入れる(受信する)ために行動するまで、できるだけ少ししかデータファイル(ボディー)を処理するべきではありません。 クライアントからのコマンドは、TCPリスナーからそうでなければ、受信機への外国の処理を積み下ろすことができるようにプレーンテキストファイルの形に保存されるかもしれません。 それで、実際に、2個のファイルがあります: コマンド・シーケンスとファイルボディー。
Troth [Page 2] RFC 1440 SIFT/UFT July 1993
信実[2ページ]RFC1440はUFT1993年7月に/をふるいわけます。
Job Entry capability:
仕事のEntry能力:
The target "user" may actually be no user at all, but may be the name of some software service engine. An example of this is the job entry queue available as a pseudo-user on many NJE networked hosts.
目標「ユーザ」は、実際に全くユーザでないかもしれませんが、あるソフトウェア業エンジンの名前であるかもしれません。 この例は疑似ユーザとして多くのNJEのネットワークでつながれたホストで利用可能なジョブエントリ待ち行列です。
4. Essential commands and Syntax:
4. 不可欠のコマンドとSyntax:
FILE size sender [auth] USER recipient
FILEサイズ送付者[auth]USER受取人
TYPE type [parm]
TYPEはタイプします。[parm]
Representation Types:
表現は以下をタイプします。
TYPE A ASCII, CR/LF (0D/0A) B binary (image; octet stream)
TYPE A ASCII、CR/LF(0D/0A)Bバイナリー(イメージ; 八重奏ストリーム)
C ASCII, CC, CR/LF (ASA print)
C ASCII、CC、CR/LF(ASA印刷)
U unformatted (binary; image) V var-length records (16 bit) W wide var-len records (32 bit) X extra-wide var-length (64 bit)
Uはvar-長さの記録(16ビット)に対してW広いvar-len記録(32ビット)のX付加的な広いvar-長さを非フォーマットしました(バイナリー;イメージ)。(64ビット)
I image (binary; octet stream) E EBCDIC, NL (15) F reclen fixed-length records (binary)
私はE EBCDIC、NL(15)F reclen固定長レコードに像を描きます(バイナリー; 八重奏ストリーム)。(2進)です。
N NETDATA M ASCII, mail
N NETDATA M ASCII、メール
Additional Parameters:
追加パラメタ:
NAME filename DATE date time [time-zone]
NAMEファイル名DATE日付の時間[時間帯]
CLASS class FORM paper-form-code or print-stock-code DEST destination
CLASSクラスFORM紙のフォームコードか印刷ストックコードDESTの目的地
DIST | BIN | BOX distribution-code or mail-stop FCB | CTAPE forms-control-buffer or carriage-tape UCS | CHARSET | TRAIN print-train or character-set
DIST| 容器| BOX分配コードかメール停止FCB| コントロールがバッファリングするCTAPEフォームかキャリッジテープUCS| CHARSET| TRAIN印刷列車か文字集合
LRECL logical-record-length RECFM record-format
LRECL論理レコード長RECFMレコード形式
Troth [Page 3] RFC 1440 SIFT/UFT July 1993
信実[3ページ]RFC1440はUFT1993年7月に/をふるいわけます。
BLKSIZE block-size
BLKSIZEブロック・サイズ
MODE file access permissions
MODEファイルアクセス許容
File disposition commands:
気質コマンドをファイルしてください:
DATA [burst-size]
データ[放出量]
EOF ABORT
EOFは中止になります。
QUIT
やめてください。
5. Details:
5. 詳細:
Commands consist of command words, possibly followed by tokens delimited by white space. Command lines are ASCII terminated by CR/LF. White space may be composed of any mixture of blanks or tab characters, but use of ordinary blank space (ASCII 0x20) is strongly recommended.
コマンドは余白によって区切られたトークンがことによるとあとに続いたコマンド単語から成ります。 コマンドラインはCR/LFによって終えられたASCIIです。 余白は空白かタブキャラクタのどんな混合物でも構成されるかもしれませんが、普通のスペース(ASCII0x20)の使用は強く推薦されます。
One connection (one socket) is used for both commands and data. While a data burst is being received, command interpretation is suspended. Command lines are read until CR/LF; data bursts are read until burst-size number of octets are received, at which point command interpretation is resumed. After data transmission has begun, the only commands valid are DATA, EOF, ABORT and QUIT. EOF causes the server to close the file at the receiving end and return to normal command processing. ABORT signals that the client wishes to discard a file partially transmitted. QUIT closes any open file, closes the connection, and can appear anywhere in the job.
1つの接続(1個のソケット)がコマンドとデータの両方に使用されます。 データ炸裂を受け取っている間、コマンド解釈は吊しています。 コマンドラインはCR/LFまで読まれます。 データ炸裂はどのポイントコマンド解釈が再開されるかで八重奏の放出量番号を受け取るまで読まれます。 データ伝送が始まった後に唯一は命令します。有効であるのは、DATAと、EOFと、ABORTとQUITです。 EOFはサーバが犠牲者にファイルを閉じて、正常なコマンド処理に戻ることを引き起こします。 クライアントがファイルを捨てたがっているというABORT信号は部分的に送信されました。 QUITはどんなオープン・ファイルも閉じて、接続を終えて、仕事でどこでも現れることができます。
For the daring, a "fast" mode is available. If the burst-size token is omitted from the DATA command, processing switches to data mode and the stream is read until the client closes the connection. In this case there is no EOF or QUIT command sent. NOTE: with the former mode of operation, the connection may remain open indefinitely passing multiple files, while in this latter case the connection must close to terminate the transaction.
勇気に、「速い」モードは利用可能です。 放出量トークンがDATAコマンドから省略されるなら、処理はデータモードに切り替わります、そして、クライアントが接続を終えるまで、ストリームは読まれます。 この場合、EOFが全くなかったか、またはQUITコマンドは発信しました。 以下に注意してください。 操作の前のモードで、接続は複数のファイルを無期限に渡しながら、開いたままで残るかもしれません、この後者の場合では、接続がトランザクションを終えるために閉じなければなりませんが。
Acknowledgement is by simple "NULL ACK". A server accepts a command by sending a single packet back to the client that starts with a NULL character, decimal 0. Anything else may be considered negative acknowledgement, and the client should close the connection. Any characters following the NULL may be ignored. An ACK response packet may signal only one acknowledgement.
承認が簡単な「ヌルACK」であります。 サーバは、0歳の10進NULLキャラクタから始まるクライアントに単一のパケットを送り返すことによって、コマンドを受け入れます。 他の何かが否定的承認であると考えられるかもしれません、そして、クライアントは接続を終えるべきです。 NULLの後をつけるどんなキャラクタも無視されるかもしれません。 ACK応答パケットは1つの承認だけに合図するかもしれません。
When a client first connects to a server, the server immediately
クライアントがすぐに最初にサーバ、サーバに接続するとき
Troth [Page 4] RFC 1440 SIFT/UFT July 1993
信実[4ページ]RFC1440はUFT1993年7月に/をふるいわけます。
sends a herald of the form:
フォームの告知を送ります:
xxx hostname UFT 1.0 server-version xxx
xxxホスト名UFT1.0サーババージョンxxx
where "xxx" represents arbitrary data. The first "xxx" must be a single blank delimited token. 1.0 is the protocol version. Hostname is the IP name of the host where this server is running. Server- version is the name and level of UFT server code on this host.
"xxx"が任意のデータを表すところ。 最初の"xxx"はただ一つの空白の区切られたトークンであるに違いありません。 1.0はプロトコルバージョンです。 ホスト名はこのサーバが稼働しているホストのIP名です。 サーババージョンは、このホストのUFTサーバコードの名前とレベルです。
A US English server might send:
米国のイギリスのサーバは発信するかもしれません:
100 ricevm1.rice.edu UFT 1.0 VM/CMS-0.9.2 ready.
100 .2が準備するricevm1.rice.edu UFT1.0VM/CMS-0.9。
The purpose of this herald is partly for client/server synchronization, but mainly for protocol agreement. There may be future versions of UFT beyond 1.0 which support more features than are outlined here. The herald indicates what level of UFT the server will accept.
この告知の目的は、一部クライアント/サーバ同期のためにありますが、主にプロトコル協定のためにあります。 UFTの将来のバージョンはここに概説されているより多くの特徴をサポートする1.0を超えているかもしれません。 告知は、サーバがUFTのどんなレベルを受け入れるかを示します。
The FILE Command:
ファイルコマンド:
FILE size from [auth]
FILEサイズ[auth]
The size is in bytes and may be followed by an 'M', 'K', or 'G', indicating Mega, Kilo, or Giga. Size may be an inexact value (the data file will be read until one of the above end-of-file indications is received). The size specified is used to answer the question, "is there room for it?"
Mega、Kilo、またはGigaを示して、サイズのバイトであって、'M'、'K'、または'G'があとに続くかもしれません。 サイズは不正確な値であるかもしれません(上のファイルの終り指摘の1つが受け取られているまで、データファイルは読まれるでしょう)。 指定されたサイズは、「それの余地がありますか?」と質問に答えるのに使用されます。
The from token is the login name of the user sending this file.
トークンから、このファイルを送るユーザのログイン名は来ています。
The auth token is an unimplemented authentication ticket. Authentication is not ensured in the protocol as described. There are several ways that it might be added to UFT over TCP, but this author will wait for authentication developments by others to come to fruition before implementing any. When UFT is piggy-backed on mail, authentication is left to the mail transfer system.
authトークンは非実装している認証チケットです。 認証は説明されるようにプロトコルで確実にされません。 それがTCPの上でUFTに加えられるかもしれないいくつかの方法がありますが、この作者は、いずれも実装する前に他のものによる認証開発が実を結ぶのを待つでしょう。 UFTがメールで背負われるとき、認証はメールトランスファー方式に残されます。
The FILE command is required in any transaction.
FILEコマンドがどんなトランザクションでも必要です。
The USER Command:
ユーザコマンド:
USER recipient
USER受取人
The recipient is a valid local user or service name.
受取人は、有効な地元のユーザかサービス名です。
The USER command is required in any transaction. Without it, the destination of the file is unknown.
USERコマンドがどんなトランザクションでも必要です。 それがなければ、ファイルの目的地は未知です。
Troth [Page 5] RFC 1440 SIFT/UFT July 1993
信実[5ページ]RFC1440はUFT1993年7月に/をふるいわけます。
The TYPE Command:
タイプは命令します:
TYPE type [parm]
TYPEはタイプします。[parm]
Some representation types need additional specification. As an example, the type "F" (fixed length, record oriented) obviously needs more qualification. How long are these fixed length records? A record length in ASCII decimal should follow the "F" resulting in a command like "TYPE F 80".
表現タイプの中には追加仕様を必要とする人もいます。 例として、タイプ「F」(固定長、適応する記録)は明らかにより多くの資格を必要とします。 これらの固定長レコードはどれくらい長いですか? ASCIIにおける記録的な長さに、小数は、「タイプF80インチ」のようなコマンドをもたらしながら、「F」に続くべきです。
UFT types V, W, X use a tape model for file transfer. Files in transit consist of blocks that vary in size based on the range of sizes specifiable with 16, 32, or 64 bits, respectively. Whether the blocking is significant to the recipient is the decision of the recipient, but if the file originally had some kind of blocking, it is preserved without additional processing. In the stream, the 16, 32, or 64-bit block length is prepended to each record in TCP/IP network order.
UFTはVをタイプして、W、Xはファイル転送にテープモデルを使用します。 トランジットにおけるファイルは16ビットか32ビットか64ビットで明記できるサイズの範囲に基づいてそれぞれ大小の差があるブロックから成ります。 受取人にとって、ブロッキングが重要であるかどうかが、受取人の決定ですが、ファイルにある種のブロッキングが元々あったなら、それは追加処理なしで保存されます。 ストリームでは、16、32、または64ビットのブロック長が、それぞれTCP/IPネットワークオーダーに記録するためにprependedされます。
Type N (NETDATA) is an IBM representation common on NJE networks.
タイプN(NETDATA)はNJEネットワークで一般的なIBMの表現です。
The TYPE command is required in any transaction.
TYPEコマンドがどんなトランザクションでも必要です。
The NAME Command:
名前コマンド:
NAME filename
NAMEファイル名
A name should typically be associated with the file being sent, although this is not mandatory. This is a mixed case token delimitted by white space. If the filename contains blanks or white space, it must be quoted. Quotation is not valid within the filename. ASCII control characters (hex 00 thru 1F and 80 thru 9F) are not valid as part of the filename. Some characters may have special meaning to the receiving operating system and their effect is not guaranteed.
名前はこれが義務的ではありませんが、送るファイルに通常関連しているべきです。 これは余白によってdelimittedされた複雑なケーストークンです。 ファイル名が空白か余白を含んでいるなら、それを引用しなければなりません。 引用はファイル名の中で有効ではありません。 ASCII制御文字(00〜1Fと80〜9F魔法をかける)はファイル名の一部として有効ではありません。 何人かのキャラクタが受信オペレーティングシステムに特別な意味を持っているかもしれません、そして、彼らの効果は保証されません。
The NAME command is optional.
NAMEコマンドは任意です。
The DATE Command:
日付のコマンド:
DATE date time [time-zone]
DATE日付の時間[時間帯]
The time stamp on the file as it appears at the sending site may be sent and applied to the copy at the receiving site. The form is US mm/dd/yy and hh:mm:ss. A time zone is optional. If the time zone is omitted, local time is assumed. If the DATE command is omitted, time and date of arrival are assumed.
ファイルの上のタイムスタンプは、送付サイトに載っているように受信サイトでのコピーに送られて、適用されるかもしれません。 フォームは、米国mm/dd/yyとhh:mm:ssです。 時間帯は任意です。 時間帯が省略されるなら、現地時間は想定されます。 DATEコマンドが省略されるなら、到着の時間と日付は想定されます。
Troth [Page 6] RFC 1440 SIFT/UFT July 1993
信実[6ページ]RFC1440はUFT1993年7月に/をふるいわけます。
The DATE command is optional.
DATEコマンドは任意です。
The DATA Command:
データは命令します:
DATA [burst-size]
データ[放出量]
If no data bursts have yet been received since the connection was opened or since an EOF or ABORT was received, the server opens a new file on the receiving end and writes this burst of data to it. The file may have already been created by a prior DATA command. There can be any number of DATA commands; most files will be sent using many data bursts. If burst-size is supplied, then burst-size number of octets are read and appended to the open file on the receiving end and the server returns to the command state. If no burst-size parameter is given, then the TCP stream is read until it is closed. (this is the "fast" mode mentioned above)
接続が開かれて以来まだデータ炸裂を全く受け取っていなかったか、またはEOFかABORTを受け取ったので、サーバは、受ける側になって新しいファイルを開いて、データのこの炸裂をそれに書きます。 ファイルは先のDATAコマンドで既に作成されたかもしれません。 いろいろなDATAコマンドがあることができます。 ほとんどのファイルに多くのデータ炸裂を使用させるでしょう。 放出量を供給するなら、受ける側になって八重奏の放出量番号をオープン・ファイルに読み込んで、追加します、そして、サーバはコマンド状態に戻ります。 放出量パラメタを全く与えないなら、それが閉じられるまで、TCPストリームを読みます。 (これは前記のように「速い」モードです)
The DATA command must come after FILE, USER, TYPE, and any other parametric commands and must come before any EOF or ABORT command. The file need not be complete before an ABORT can be received and carried out, but the DATA command must have completed (burst-size number of octets must have been read), thus ABORT is not possible in "fast" mode.
DATAコマンドは、FILE、USER、TYPE、およびいかなる他のパラメトリックコマンドにも続かなければならなくて、どんなEOFやABORTも命令する前に来なければなりません。 DATAコマンドは(八重奏の数が読み込まれたに違いない放出量)を完成したに違いありません、そして、ABORTを受け取って、行うことができる前にファイルは完全である必要はありませんが、その結果、ABORTは「速い」モードで可能ではありません。
The EOF Command:
EOFは命令します:
EOF
EOF
This signals the server that the entire file has been sent. The server then closes the file and ensures that it is disposed of appropriately, usually just placing it where a user-level application can retrieve it later.
これは、ファイル全体が送られたとサーバに合図します。 サーバは、次に、ファイルを閉じて、それが適切に処分されるのを確実にします、通常、ただユーザレベルアプリケーションが後でそれを検索できるところにそれを置いて。
The ABORT Command:
中止コマンド:
ABORT
アボート
This signals the server that the client is unable or unwilling to finish the job. The file should be discarded and the server should return to normal command processing.
これは、クライアントが仕事を終えたがっていないとサーバに合図します。 ファイルは捨てられるべきです、そして、サーバは正常なコマンド処理に戻るべきです。
The QUIT Command:
辞任コマンド:
QUIT
やめてください。
This signals the server that all work is complete. Any open file should be closed and delivered. The TCP stream will be closed.
これは、すべての仕事が完全であるとサーバに合図します。 どんなオープン・ファイルも、閉じられて、提供されるべきです。 TCPストリームは閉じられるでしょう。
Troth [Page 7] RFC 1440 SIFT/UFT July 1993
信実[7ページ]RFC1440はUFT1993年7月に/をふるいわけます。
Other commands:
他のコマンド:
CLASS class FORM paper-form-code or print-stock-code DEST destination DIST distribution-code or mail-stop FCB forms-control-buffer or carriage-tape CHARSET print-train or character-set
CLASSクラスFORM紙のフォームコード、印刷ストックコードDEST目的地DIST分配コード、フォームがバッファを制御しているか、またはキャリッジでテープに録音しているCHARSETが印刷で訓練するメール停止FCBまたは文字集合
The above are relevant to print jobs sent to a print server.
上記は、プリント・サーバに送られた仕事を印刷するために関連しています。
LRECL logical-record-length RECFM record-format BLKSIZE block-size MODE file access permissions
LRECL論理レコード長RECFMレコード形式BLKSIZEブロック・サイズMODEファイルアクセス許容
6. References
6. 参照
NJE -- Network Job Entry; IBM publication SC23-0070, "Network Job Entry; Formats and Protocols"
NJE--ジョブエントリをネットワークでつないでください。 IBMの公表SC23-0070、「ネットワークジョブエントリ」。 「形式とプロトコル」
NETDATA -- see IBM publication aann-nnnn (SC24-5461); VM/ESA: CMS Application Development Reference for Assembler
NETDATA--IBMの公表aann-nnnn(SC24-5461)を見てください。 VM/ESA: アプリケーション開発がアセンブラのために参照をつけるcm
BITNET -- "Because It's Time"; academic network based on NJE protocol
Bitnet--「時間であるので」。 NJEプロトコルに基づくアカデミックなネットワーク
MIME -- RFC 1341; Multipurpose Internet Mail Extensions; Borenstein & Freed
まねてください--RFC1341 マルチパーパスインターネットメールエクステンション。 Borensteinであって解放されています。
FTP -- File Transfer Protocol; STD 9, RFC 959; Postel & Reynolds
FTP--ファイル転送プロトコル。 STD9、RFC959。 ポステルとレイノルズ
SMTP -- STD 10, RFC 821; Simple Mail Transfer Protocol; Postel
SMTP--STD10、RFC821。 簡単なメール転送プロトコル。 ポステル
LPR -- UNIX Programmer's Manual, LPD(8); 4.2BSD Line Printer Spooler Manual
LPR--UNIXプログラマのマニュアル、LPD(8)。 4.2BSDラインプリンタスプーラマニュアル
7. Security Considerations
7. セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
Troth [Page 8] RFC 1440 SIFT/UFT July 1993
信実[8ページ]RFC1440はUFT1993年7月に/をふるいわけます。
8. Author's Address
8. 作者のアドレス
Rick Troth Rice University Information Systems Houston, Texas 77251
リック・信実ライス大学Information Systemsヒューストン、テキサス 77251
Phone: (713) 285-5148 Fax: (713) 527-6099 EMail: troth@rice.edu
以下に電話をしてください。 (713) 285-5148 Fax: (713) 527-6099 メールしてください: troth@rice.edu
Troth [Page 9]
信実[9ページ]
一覧
スポンサーリンク