RFC520 日本語訳

Network Working Group                                             J. Day
Request for Comments: 520                Center for Advanced Computation
NIC: 16819                                                  25 June 1973

コメントを求めるワーキンググループJ.日の要求をネットワークでつないでください: 520 高度な計算NICのためのセンター: 16819 1973年6月25日

             A Proposed File Access Protocol Specification

提案されたファイルアクセスプロトコル仕様

   Attached is a proposal for the File Access Protocol.  FAP is an
   extension to FTP.  I believe the specification is fairly general and
   should provide a good jumping-off place.  I hope the protocol is
   specified in such a way as to fit with idiosyncrasies of most
   systems.  If the protocol would cause an inordinate amount of burden
   on your system for one reason or another I would like to hear about
   it.

File Accessプロトコルのための提案を付けます。 FAPはFTPへの拡大です。 私は、仕様がかなり一般的であると信じて、良い人里離れた所を前提とするべきです。 プロトコルがほとんどのシステムの特異性と合うほどそのような方法で指定されることを願っています。プロトコルがあなたの何らかの理由のシステムの上の過度の量の負担を引き起こすなら、それについて聞きたいと思います。

   At some later date when the difficulties of implementation are better
   known, I would like to see several levels of implementation specified
   and implementation be done in terms of those levels.

実装の困難が、よりよく知られている、いくつかのレベルの実装が指定されるのを見たいと思ういつかの後の期日と実装では、それらのレベルで、してください。

   From rumors I have heard I believe this will also allow creation and
   transfer of what TENEX calls "holey" files.  But, I am not sure of
   all of the implications of that, or what would happen (or should
   happen) when a "holey" file is moved to a site that doesn't really
   have such a thing, per se.  Comments from the TENEX crowd would be
   appreciated.

噂から、私は、また、これが"holey"がどんなTENEX呼び出しをファイルするかに関する作成と転送を許容すると信じていると聞きました。 しかし、私は"holey"ファイルが本当にそういうもののそのようなものを持っていないサイトに動かされるとき、thatか何が起こるだろうかに関する(または、起こるべきです)含意のすべてを確信していません。 TENEX群衆からのコメントをよろしくお願いします。

   I think some further work could be done to make FAP easier for record
   oriented systems.  This would probably require an extra command or
   parameter to specify all operations are in terms of records.
   Comments are invited.

私は、記録的な指向のシステムこれはすべての操作を指定するためにたぶん付加的なコマンドかパラメタを必要とするでしょう、したがって、記録に関してFAPをより簡単にするようにさらなる仕事をできた或るものがあると思います。 コメントは招待されます。

   In the long run though, I would like to see FAP thrown away.  The
   commands as they are described merely add a finer structure to the
   present RETR, STOR, and APPE without much additional overhead.  The
   sequence:

もっとも、結局、FAPが捨てられるのを見たいと思います。 コマンド、それらが単に説明されるように、多くの追加オーバーヘッドなしで現在のRETR、STOR、およびAPPEによりすばらしい構造を加えてください。 系列:

      OPEN R FOO.BAR CRLF
            READ ALL CRLF
            CLOS CRLF

開いているR FOO.BAR CRLFはすべてのCRLF CLOS CRLFを読みます。

   is equivalent to RETR FOO.BAR CRLF.  FAP could be merged with FTP to
   give a much richer, coherent whole.

RETR FOO.BAR CRLFには同等物がありますか? はるかに豊かで、一貫性を持っている全体を与えるためにFAPをFTPに合併できました。

   In writing this document, I ran into the deficiency of reply codes
   for protocols.  Three digits is no where near enough.  I would like
   to suggest that as another interim solution we go to a five digit

このドキュメントを書く際に、私はプロトコルのために回答コードの欠乏を出くわしました。 3ケタは十分近いところのノーです。 私たちが5ケタまで行かせる別の当座のソリューションとしてそれを勧めたいと思います。

Day                                                             [Page 1]

RFC 520      A Proposed File Access Protocol Specification  25 June 1973

提案されたファイルアクセスプロトコル仕様1973年6月25日あたり日[1ページ]のRFC520

   reply with two for specific categories (such as Primary access, FTP
   results, etc.) and two for specific results.  In the meantime, the
   NWG should begin considering a general scheme for reply codes -- one
   that doesn't need revising every two years.

特定のカテゴリ(Primaryアクセス、FTP結果などの)のための2と特定の結果のための2で、返答してください。 差し当たり、NWGは、回答コードの一般的な体系を考え始めるはずです--2年毎に復習する必要はないもの。

   Comments, complaints, etc. are welcomed.  I may be reached through
   network mail at ISI (DAY) or Multics (DAY Cnet) or by phone at the
   University of Illinois (217) 333-6544.

コメント、苦情などは歓迎されます。 ネットワークメールで私はISI(DAY)かMultics(DAY Cnet)において、または、イリノイ(217)大学333-6544の電話で連絡されるかもしれません。

                                    A
                                 Proposed
                           File Access Protocol
                               Specification

提案されたファイルアクセスプロトコル仕様

                                 John Day

ジョンデイ

                                  6/7/73

6/7/73

I. INTRODUCTION

I. 序論

   The purpose of the File Access Protocol is to provide a method for
   processes to access non-local files in either a sequential or non-
   sequential manner.  Unlike the proposed Mail Protocol, FAP is an
   extension of FTP and not a subsystem.  In general FAP is compatible
   with the rest of FTP.  Those modifications which are necessary are
   specified below.

File Accessプロトコルの目的はプロセスが連続したか非連続した方法による非ローカルファイルにアクセスするメソッドを提供することです。 提案されたメールプロトコルと異なって、FAPはサブシステムではなく、FTPの拡大です。 一般に、FAPはFTPの残りと互換性があります。 それらの必要な変更は以下で指定されます。

   The intent of this protocol is to allow processes to specify to the
   remote file system where in the file they wish the next operation to
   start and how much data to move.  Thus only the part of a file
   necessary for a process' computation need be transferred, rather than
   the entire file.  Thus transmission times and storage requirements
   may be held down.  In short, the rationale for a File Access Protocol
   on the network is the same as the rationale for "random-accessed"
   files in a standard operating system.

このプロトコルの意図はプロセスがファイルでは、彼らが始まるようにどこで次の操作を願うか、そして、どのくらいのデータを動かすかをリモートファイルシステムに指定するのを許容することです。 したがって、ファイル全体よりむしろ過程の計算に必要なファイルの部分だけを移さなければなりません。 したがって、トランスミッション時間とストレージ要件は押さえられるかもしれません。 要するに、ネットワークのFile Accessプロトコルのための原理は標準のオペレーティングシステムによる「無作為にアクセスされた」ファイルのための原理と同じです。

   The file Access Protocol uses the connection model, data
   representations, and transmission methods of the File transfer
   Protocol.  All data transmissions in FAP are handled according to the
   description in FTP Section III.C with the following modifications.
   In Stream mode, the minimum byte size is increased to 4 bits.
   Another control code (value 4) is used to indicate "end of
   transmission".  An combination of EOT, EOR, or EOF may be indicated
   by the proper control code.  With this method it is not necessary to
   close the connection after each access; a practice not highly
   recommended.  In Block mode, bit 5 of the descriptor field of the
   header is set noting that this block is the end of transmission.  In
   addition to this, FAP uses a File Pointer (FP).  The file pointer

ファイルAccessプロトコルは接続モデル、データ表現、およびFile転送プロトコルの透過法を使用します。 記述によると、FAPのすべてのデータ伝送がFTPセクションIII.Cで以下の変更で扱われます。 Streamモードで、最小のバイトサイズは4ビットまで増強されます。 別の制御コード(値4)は、「トランスミッションの端」を示すのに使用されます。 EOT、EOR、またはEOFの組み合わせは適切な制御コードによって示されるかもしれません。 このメソッドで、各アクセスの後に接続を終えるのは必要ではありません。 強く推薦されなかった習慣。 Blockモードで、ヘッダーの記述子分野のビット5はこのブロックがトランスミッションの端であることに注意するように設定されます。 これに加えて、FAPはFile Pointer(FP)を使用します。 ファイル・ポインタ

Day                                                             [Page 2]

RFC 520      A Proposed File Access Protocol Specification  25 June 1973

提案されたファイルアクセスプロトコル仕様1973年6月25日あたり日[2ページ]のRFC520

   points into the file and is the point at which the next FAP read or
   write will commence.  The file pointer is a general mechanism for
   addressing a file and should be flexible enough to handle both stream
   and record oriented systems.

ファイルの中に指して、次のFAPが読むか、または書くポイントが始まるということです。 ファイル・ポインタは、ファイルを扱うための一般的機構であり、ストリームと記録的な指向のシステムの両方を扱うほどフレキシブルであるべきです。

II.  PROBLEMS OF IMPLEMENTATION

II。 実装の問題

   As usual, not all systems will be able to implement this protocol in
   its full generality.  The approach that should be taken is that no
   host should be required to provide for network users (in the name of
   complete protocol implementation) service it does not provide its
   local users.

いつものように、すべてのシステムがどんな完全な一般性におけるこのプロトコルを実装することができるというわけではないでしょう。 取られるべきであるアプローチはホストが全くそれが地元のユーザに提供しないネットワーク利用者(完全なプロトコル実装の名にかけて)サービスに備えるのが必要であるべきでないということです。

   Some systems allow "random" access to some kinds of files on its
   system and not to others.  In this case, this should be their
   implementation, i.e., not all operations are valid for all kinds of
   files.

いくつかのシステムが他のものではなく、そのシステムの数種類のファイルへの「無作為」のアクセスを許します。 この場合これがそれらの実装であるべきである、すなわち、すべての種類のファイルに、すべての操作がどんな有効であるというわけではありません。

   Some systems cannot move the byte pointer backwards without opening
   and closing the file.  They should not be required to do this
   (although they may if they wish), but they should allow "spacing"
   down a file some distance before starting a transfer.

ファイルを開いて、閉じないで、いくつかのシステムはバイト指針を後方に動かすことができません。 それらはこれをするのが必要であるべきではありませんが(彼らが願うなら、そうするかもしれませんが)、転送を始める前に、彼らはファイルの下側への「スペース」に何らかの距離を許すべきです。

   Some systems may not allow read and write access to be available
   without closing and reopening the file.  Systems should not be
   required to do both.

システムが許容しないかもしれない或るものは、ファイルを閉じて、再開させないで利用可能になるようにアクセスを読み書きします。 両方をするためにシステムを必要とするべきではありません。

      In general, the rules of implementation are:

一般に、実装の規則は以下の通りです。

      1) If a system normally allows that particular kind of access to
      that particular file then it should be allowed; if not, the system
      should not be forced to implement it. (In many cases, the legality
      cannot be known until the operation is attempted; i.e., it cannot
      be told of the first two cases above if they are legal when the
      file is opened but only on the read or write which violates the
      implementation restrictions).

1) システムが通常その特定のファイルへのその特定の種類のアクセスを許すなら、それは許容されるべきです。 そうでなければ、システムはやむを得ずそれを実装するはずがありません。 (多くの場合、操作が試みられるまで、合法を知ることができません。 すなわち、上の最初の2つのケースについてしかし、ファイルが読みで開かれるとき、法的であるか、または書くならどれが施行規則に違反するかと言うことができない、)

      2) A system should not try to simulate a facility if the
      simulation has side effects.  For example, if simulating the
      capability of moving the byte pointer to the desired position has
      some side effects, then the simulation should be left to the
      process accessing the file.

2) シミュレーションに副作用があるなら、システムは施設をシミュレートしようとするはずがありません。 例えば、必要な位置へのバイト指針には、移行する能力をシミュレートするなら、いくつかの副作用があって、次に、シミュレーションはファイルにアクセスするプロセスに残されるべきです。

      3) All implementors should make known the capabilities of their
      implementations via NIC documents.

3) すべての作成者がNICドキュメントでそれらの実装の能力を明らかにするべきです。

Day                                                             [Page 3]

RFC 520      A Proposed File Access Protocol Specification  25 June 1973

提案されたファイルアクセスプロトコル仕様1973年6月25日あたり日[3ページ]のRFC520

III.  FILE ACCESS PROTOCOL

III。 ファイルアクセスプロトコル

   The FAP extension to FTP includes 6 new commands and the file
   pointer.  Any implementation requires the file pointer and all six
   commands.  But, as described above, it is not necessary to implement
   the commands in their full generality.

FTPへのFAP拡張子は6つの新しいコマンドとファイル・ポインタを含んでいます。 どんな実装もファイル・ポインタとすべての6つのコマンドを必要とします。 しかし、上で説明されるように、それらの完全な一般性におけるコマンドを実装するのは必要ではありません。

III.1 THE FILE POINTER

III.1ファイル・ポインタ

   The file pointer represents an index or address within the file.  The
   units by which the index is measured, is "logical byte size" and does
   not include any bytes related to transmission or structure.  In
   particular, for transmission mode Stream and structure Record, the
   EOR and EOF markers are not counted.  Local transformations on data
   must be taken into account.  For example, Multics stores CRLF as NL.
   In this case, NL counts as two ASCII bytes since it was transmitted
   to or will be sent from Multics as CRLF.  If transmission Mode is
   Image then the logical byte size is taken as the transmission byte
   size.  There are two commands which operate on the file pointer: 1)
   SETP to move the pointer and 2) GETP to find out where it is at.
   These are described below in more detail.

ファイル・ポインタはファイルの中にインデックスかアドレスを表します。 インデックスが測定されて、「論理的なバイトサイズ」であり、どんなバイトも含んでいないユニットはトランスミッションか構造に関連しました。 転送方式Streamと構造Recordにおいて、特に、EORとEOFマーカーは数えられません。 データにおける局所変形を考慮に入れなければなりません。 例えば、MulticsはNLとしてCRLFを保存します。 この場合、NLは、それを伝えたか、またはCRLFとしてMulticsから送るので、2ASCIIバイトとして数えます。 トランスミッションModeがImageであるなら、論理的なバイトサイズはトランスミッションバイトサイズとしてみなされます。 ファイル・ポインタを作動させる2つのコマンドがあります: 1) 指針と2を)動かすSETP 見つけるそれがあるGETP。 これらは以下でさらに詳細に説明されます。

   The file pointer may take on three classes of values.  All may be
   mapped to some decimal number.  The value B represents the beginning
   of the file (Byte 0).  The value E represents the end of the file (or
   Byte n for a file n bytes long).  The byte pointer may also take on
   any value between 0 and n.

ファイル・ポインタは3つのクラスの値を呈するかもしれません。 すべてが何らかの10進数に写像されるかもしれません。 値Bはファイル(バイト0)の始まりを表します。 値Eはファイル(または、n長さバイトのファイルのためのByte n)の端を表します。 また、バイト指針は0とnの間にどんな値も呈するかもしれません。

                       A file of n bytes

nバイトのファイル

                          ..........
     |----|----|----|----|-----------|----|----|----|----|
     ^    1    2    3    4          n-4  n-3  n-2  n-1   ^
     |                                                   |
     0                                                   n
     B                                                   E

.......... |----|----|----|----|-----------|----|----|----|----| ^1 2 3 4n-4 n-3 n-2 n-1^| | 0 n B E

   If a file is stored under set of parameters (TYPE, etc.) and
   operations are attempted on it under different parameters, the server
   does not guarantee that the information will be valid.

ファイルがパラメタ(TYPEなど)のセットの下で保存されて、操作がそれで異なったパラメタの下で試みられるなら、サーバは、情報が有効になるのを保証しません。

III.2 COMMANDS

III.2コマンド

III.2.1 OPEN <direction> <pathname>

III.2.1の開いている<方向><パス名>。

   This command instructs the server to "open" the file <pathname> for
   access in the direction specified.  The directions are read, R write,
   W; or both, B. A read direction implies that the data connection is

このコマンドは、方向へのアクセスのための>が指定したファイル<パス名を「開く」ようサーバに命令します。 W、Rは方向が読まれると書きます。 または、ともに、方向が読まれたB.Aは、データ接続がそうであることを含意します。

Day                                                             [Page 4]

RFC 520      A Proposed File Access Protocol Specification  25 June 1973

提案されたファイルアクセスプロトコル仕様1973年6月25日あたり日[4ページ]のRFC520

   from server to user; write, from user to server; and both implies
   connections each ways.  Functionally, this command corresponds to
   RETR or STOR.  Therefore, all the FTP parameter commands (TYPE, MODE,
   etc.)  must be sent before the file is opened.  If the direction is
   write (W) and the file specified by the pathname does not exist,
   there is an implied create with the open.  The success of this
   create, is, of course, dependent on local access privileges and
   possibly whether or not an ALL command was sent.  If applicable, the
   file created should be of the most general kind of file on which
   "random" access is allowed. (This is to allow the largest degree of
   compatibility with operations that may follow).  This should be
   ignored if some site specific command has already specified the kind
   of file.  This command identifies the file on which subsequent
   operations are to be performed.  After the file is opened, the file
   pointer is at B and any of the other five FAP commands may be sent.
   It is acknowledged that some systems cannot open a file for access in
   both directions; an error reply 402 should be sent for this response.

サーバからユーザまで。 ユーザからサーバまで書いてください。 そして、両方がそれぞれ接続を含意します。道。 機能上、このコマンドはRETRかSTORに対応しています。 したがって、ファイルを開く前にすべてのFTPパラメタコマンド(TYPE、MODEなど)を送らなければなりません。 方向が(W)を書くことであり、パス名によって指定されたファイルが存在していないなら、ある、暗示、戸外で、作成します。 この成功が作成する、もちろん地方のアクセス権とことによると、すべてのコマンドを送ったかどうかに依存しています。 適切であるなら、作成されたファイルは「無作為」のアクセスが許されている最も一般的な種類のファイルのものであるはずです。 (これは続くかもしれない操作との最も大きい度合いの互換性を許容するためのものです。) 何らかのサイトの特定のコマンドが既にファイルの種類を指定したなら、これは無視されるべきです。 このコマンドは実行されるその後の操作がことであるファイルを特定します。 ファイル・ポインタはBのファイルが開かれる後です、そして、他の5つのFAPコマンドのいずれも送るかもしれません。 いくつかのシステムが両方の方向にアクセスのためのファイルを開くことができないと認められます。 この応答のためにエラー応答402を送るべきです。

   Replies
   -------
   258      451       500       504       550
   402      454       501       505
   434      455       502       506
   4550     457       503       507

返信------- 258 451 500 504 550 402 454 501 505 434 455 502 506 4550 457 503 507

III.2.2 SETP <argument>

III.2.2SETP<議論>。

   This command causes the file pointer to be set to the number
   specified in the argument.  This value will be the ordinal number of
   the starting position of the next operation. (Byte 0 is the first
   byte in the file).  The argument may take on two other values besides
   <decimal number> : B, for BEGIN, which sets the file pointer at the
   beginning of a file (i.e. 0) and E, for END, which sets the file
   pointer to the last byte in the file.  Two error conditions are
   possible.  If the argument specifies an illegal change of file
   pointer (such as moving it backwards on some systems), then the error
   reply 402 should be sent.  If the argument attempts to move the file
   pointer off the end of the file, then the EOF: <byte number> reply
   should be sent with the address of the end of the file (E), and the
   file pointer left at E.

このコマンドで、議論で指定された数にファイル・ポインタを設定します。 この値は次の操作の開始位置の序数詞になるでしょう。 (バイト0はファイルで最初のバイトです。) 議論は<10進数>以外に他の2つの値を呈するかもしれません: BEGINのためのファイル(すなわち、0)の始めにファイル・ポインタを設定するBとENDのためのファイルにおける最後のバイトにファイル・ポインタを設定するE。 2つのエラー条件が可能です。 議論がファイル・ポインタ(いくつかのシステムの上でそれを後方に動かすことなどの)の不法な変化を指定するなら、エラー応答402を送るべきです。 議論が、ファイル・ポインタを次に、ファイル、EOFの端に動かすのを試みるなら: 送られるべきである数の>がファイル(E)の端のアドレス、およびファイル・ポインタで返答する<バイトはEでいなくなりました。

   Replies
   -------
   258
   402
   480

返信------- 258 402 480

Day                                                             [Page 5]

RFC 520      A Proposed File Access Protocol Specification  25 June 1973

提案されたファイルアクセスプロトコル仕様1973年6月25日あたり日[5ページ]のRFC520

III.2.3 GETP

III.2.3GETP

   This command requests the server to return the value of the file
   pointer as a decimal number.

このコマンドは、10進数としてファイル・ポインタの値を返すようサーバに要求します。

   Reply
   -----
   483
   504

返信----- 483 504

III.2.4 READ <arg>

III.2.4は<arg>を読みます。

   This command instructs the server to move as many bytes as specified
   (of size logical byte size) from the server to the user.  The values
   the argument may take on are <decimal number> and ALL.  ALL is
   interpreted as all data from the present position of the file pointer
   to the end-of-file.  If a read requests more bytes than in the file,
   the number of bytes from the present position to the end of file
   should be transferred and an EOF: <byte number> response returned
   noting the position of the end of file.  If the file is Record
   structured and a READ requests more bytes than in the record, then
   the number of bytes in the record from the file pointer are moved and
   the EOR: <byte number> reply is sent noting the end of record.  The
   action of a READ leaves the file pointer at the position before the
   read plus the number of bytes moved, (i.e., updated).  The EOF
   condition leaves it at E.

このコマンドは、多くのバイトとして移行するためにサーバからユーザまで指定されているとして(サイズの論理的なバイトサイズの)サーバを命令します。 議論が呈するかもしれない値は、<10進数>とすべてです。 すべてがそうです。ファイル・ポインタの現職からファイルの終りにすべてのデータを解釈しました。 ファイルより多くの読み出し要求バイトであるなら、現職からファイルの終りまでのバイト数は、わたってEOFであるべきです: <バイト数の>応答は、ファイルの終りの位置に注意しながら、戻りました。 ファイルが構造化されたRecordであり、READが記録より多くのバイトを要求するなら、ファイル・ポインタからの記録のバイト数は、動いてEORです: <バイト数の>回答に記録の終わりを注意させます。 READの機能は読みとバイト数の前に動いて、(すなわち、アップデートされる)の位置にファイル・ポインタを残します。 EOF状態はEでそれを残します。

   Replies
   -------
   258      480
   402      481
   450      482
   452      500-507
   455

返信------- 258 480 402 481 450 482 452 500-507 455

III.2.5 WRITe <arg>

III.2.5は<arg>に書きます。

   This command instructs the server to accept as many bytes as
   specified from the user.  The result updates the value of the file
   pointer.  The values the argument may take on are <decimal number> or
   ALL.  ALL is interpreted as all data from the present position of the
   byte pointer to the end-of-file (or beyond).  Associated with the
   write is an implied "append", if necessary previous information has
   been sent (such as allocation) and if the file's access privilege
   allow the append.  If a write specifies more bytes than there are
   between the file pointer and the end-of-file, and expansion is not
   allowed, no data is sent and the file pointer is not moved.  An error
   is returned specifying the byte position of the EOF.  If the file is

このコマンドは、同じくらい多くのバイトがユーザから指定されていると受け入れるようサーバに命令します。 結果はファイル・ポインタの値をアップデートします。 議論が呈するかもしれない値は、<10進数>かすべてです。 すべてがすべてのデータとしてバイト指針の現職からファイルの終り(or beyond)まで解釈されます。 交際する、書く、暗示している「追加」、(配分としてのそのようなもの)とファイルのものが特権にアクセスするかどうかという必要なら前の情報を送ったということである、許容、追加します。 指定する、aが、書くファイル・ポインタとファイルの終りの間には、そこより多くのバイトがあって、拡張を許さないで、またデータを全く送らないで、またファイル・ポインタを動かしません。 誤りは、EOFのバイト位置を指定しながら、返されます。 ファイルがそうなら

Day                                                             [Page 6]

RFC 520      A Proposed File Access Protocol Specification  25 June 1973

提案されたファイルアクセスプロトコル仕様1973年6月25日あたり日[6ページ]のRFC520

   Record structured and a WRIT attempts to move more bytes than there
   are in the record, the file pointer is not moved and the EOR: <byte
   number> reply is sent noting the end of record.

構造化された記録と記録にあるより多くのバイトを動かすWRIT試み、ファイル・ポインタは、動かないでEORです: <バイト数の>回答に記録の終わりを注意させます。

   Replies
   -------
   258      480
   402      481
   450      482
   452      500-507
   453

返信------- 258 480 402 481 450 482 452 500-507 453

III.2.6 CLOS

III.2.6CLOS

   This command instructs the server to "close" the presently open file,
   if any.  The receipt of a CLOS without an open file is not an error.
   The effect is to notify the server that further operations are not
   directed at the file which is presently open.  If an open is received
   by the server and it has a file open, it should close the open file
   and open the new one.

このコマンドは、現在開いているファイルを「閉じる」ようもしあればサーバに命令します。 オープン・ファイルのないCLOSの領収書は誤りではありません。 効果は現在開いているファイルがさらなる操作に向けられないようにサーバに通知することです。 サーバで戸外を受け取って、ファイルを開かせるなら、それは、オープン・ファイルを閉じて、新しい方を開くべきです。

   Reply
   -----
   258

返信----- 258

IV.  SUMMARY

IV。 概要

IV.1 SYNTAX

IV.1構文

   OPEN <direction> <pathname> CRLF
   CLOS CRLF
   SETP <byte pointer arg> CRLF
   GETP CRLF
   READ <transfer argument> CRLF
   WRIT <transfer argument> CRLF

オープン<方向><パス名>CRLF CLOS CRLF SETP<バイト指針arg>CRLF GETP CRLF READ<転送議論>CRLF WRIT<転送議論>CRLF

   <direction>::= R|W|B

<方向>:、:= R|W|B

   <byte pointer argument>::= B|E|<decimal number>

<バイト指針議論>:、:= B|E|<10進数>。

   <transfer argument>::=ALL|<decimal number>

<転送議論>:、:=すべて|<10進数>。

   <byte number>::= <decimal number>

<バイト数の>:、:= <10進数>。

Day                                                             [Page 7]

RFC 520      A Proposed File Access Protocol Specification  25 June 1973

提案されたファイルアクセスプロトコル仕様1973年6月25日あたり日[7ページ]のRFC520

IV.2 REPLIES USED BY FAP

FAPによって使用されたIV.2回答

   258    Operation successful
   402    Command not implemented for requested value or action
   433    Cannot transfer files w/o valid account. Enter account &
          resend command.
   450    FTP: file not found
   451    FTP: file access denied
   452    FTP: file transfer incomplete, data connection closed.
   453    FTP: file transfer incomplete, insufficient storage space.
   454    FTP: cannot connect to your data socket
   455    FTP: file system error not covered by other reply codes.
   457    FTP: transfer parameters in error.
   480    EOR: <byte number>
   481    EOF: <byte number>
   482    File not open for operation
   483    FP: <byte pointer>
   500    Last command line completely unrecognized.
   501    Syntax of last command is incorrect.
   502    Last command invalid (ignored), illegal parameter combination.
   504    Last command invalid, action not possible at this time.
   505    Last command conflicts illegally with previous command(s).
   506    Last command not implemented by the server.
   507    Catchall error reply.
   550    Bad pathname specification (e.g., syntax error).

258 操作のうまくいっている402Commandは、要求された値か動作のために有効なアカウントなしで433Cannot転送がファイルであると実装しませんでした。 勘定を記帳してください、そして、コマンドを再送してください。 450FTP: ファイルが見つからない、451FTP: ファイルアクセスは452FTPを否定しました: 不完全なファイル転送データ接続は閉じました。 453FTP: ファイル転送の不完全で、不十分な集積スペース。 454FTP: あなたのデータソケットに455FTPを接続できません: 他の回答コードでカバーされなかったシステム誤りをファイルしてください。 457FTP: パラメタを間違って移してください。 480EOR: <バイトNo.>481EOF: 482Fileが操作483FPのために開かない<バイト数の>: <バイト指針>500Lastコマンドライン、完全に認識されていません。 持続コマンドの501構文は不正確です。 502は最後に無効(無視される)の、そして、不法なパラメタ組み合わせを命令します。 504はコマンド病人、このとき可能でない動作が続きます。 505 持続コマンドは不法に前のコマンドと衝突します。 506 持続コマンドは、サーバで. 507Catchallがエラー応答であると実装しませんでした。 550 悪いパス名仕様(例えば、構文エラー)。

         [ This RFC was put into machine readable form for entry ]
               [ into the online RFC archives by Via Genie ]

[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした][Via GenieによるオンラインRFCアーカイブへの]

Day                                                             [Page 8]

日[8ページ]