RFC532 日本語訳

0532 UCSD-CC Server-FTP facility. R.G. Merryman. July 1973. (Format: TXT=7298 bytes) (Status: UNKNOWN)
プログラムでの自動翻訳です。
英語原文

Network Working Group                                        R. Merryman
Request for Comments: 532                                        UCSD-CC
NIC: 17451                                                  12 July 1973

コメントを求めるワーキンググループR.道化師要求をネットワークでつないでください: 532 UCSD-CC NIC: 17451 1973年7月12日

                    The UCSD-CC Server-FTP Facility

UCSD-CCサーバFTP施設

1.0 Introduction

1.0 序論

   The UCSD Computer Center is a service site that must support itself
   by charging for the usage of its facilities.  Because of this, the
   prospective user of our Server-FTP must supply a valid usercode
   (USER) and password (PASS) before any further FTP commands are
   accepted.

UCSDコンピュータセンターは施設の使用法に課金することによって自活しなければならないサービスサイトです。 これのために、どんなさらなるFTPコマンドも受け入れる前に、私たちのServer-FTPの将来のユーザは有効なusercode(USER)とパスワード(PASS)を提供しなければなりません。

   Through FTP, you are allowed to access or store files on our disk or
   on any of our 7 or 9-track tape drives.  Each individual file
   transfer is handled by a separate process on the B6700 and the user
   is charged for the processor, I/O, core, and (if any) tape charges
   incurred by this process (note that these charges are quite minimal).
   Each of these transfer processes is given a separate "job" number and
   is therefore billed separately for each transfer by our accounting
   system.

FTPを通して、私たちのディスクか私たちの7か9道のテープドライブのどれかのファイルをアクセスするか、またはあなたは保存できます。 それぞれの個々のファイル転送はB6700の上の別々のプロセスによって扱われます、そして、ユーザはプロセッサ(このプロセス(これらの充電がかなり最小限であることに注意する)によって被られた入出力、コア、および(もしあれば)テープ充電)のために請求されます。 それぞれのこれらの転送プロセスを別々の「仕事」番号を与えて、したがって、私たちの会計システムは各転送のために別々に請求します。

   Please note that we have implemented FTP as defined in RFC# 354 (July
   8, 1972) except as noted.

私たちは注意されるのを除いて、RFC#354(1972年7月8日)で定義されるようにFTPを実装しました。

2.0 FTP Commands

2.0 FTPコマンド

(1)   USER

(1) ユーザ

      As mentioned, you must supply a legal, known, UCSD--CC user-code.
      Following which, the "230" message will be given, asking for the
      corresponding password.

言及されるように、あなたは法的で、知られているUCSDを供給しなければなりません--CCユーザコード。 どれに続いて、対応するパスワードを求めて、「230」メッセージを与えるでしょう。

(2)   PASS

(2) パス

      After the 'USER' command is accepted, you must then enter the PASS
      command giving the corresponding password.  If the usercode and
      password are of correct form, if they match, if there is money in
      your account, if your account is active, and if you are authorized
      for "Q1" service, then you will be properly logged-on and the
      "230" response will be returned.

そして、'USER'コマンドを受け入れた後に、あなたは、対応するパスワードを与えながら、PASSコマンドを入力しなければなりません。 彼らが合っているならusercodeとパスワードが訂正用紙のものであり、あなたのアカウントがアクティブであるならあなたのアカウントでお金があって、あなたが「Q1"サービス、次に、適切にあなたにログオンするでしょう、そして、「230」応答を返す」ために権限を与えられるなら。

(3)   BYTE

(3) バイト

      We allow only the (default) byte-size of "8" - all others will be
      rejected.

私たちは「何8インチも、すべての他のものが拒絶される」(デフォルト)バイト-サイズだけを許します。

Merryman                                                        [Page 1]

RFC 532             The UCSD-CC Server-FTP Facility         12 July 1973

道化師[1ページ]RFC532UCSD-CCサーバFTP施設1973年7月12日

(4)   MODE

(4) モード

      We only allow the (default) mode of "S" (Stream) - all others will
      be rejected

私たちは「S」(ストリーム)の(デフォルト)モードを許すだけです--すべての他のものが拒絶されるでしょう。

(5)   TYPE

(5) タイプ

      We allow "A" (ASCII) and "I" (Image) types - all others will be
      rejected.  As in standard-FTP, "A" is default.

私たちは(ASCII)と「私」(イメージ)タイプを許します--すべての他のものが拒絶されるでしょう。 標準のFTPのように、「A」はデフォルトです。

(6)   STRU

(6) STRU

      We allow both "F" (file) and "R" (Record) structuring.  Record-
      structuring is meaningful only in ASCII/Stream, where CRLF is used
      as End-of-Line.  When using Record-structuring in a STOR to us, if
      an incoming record is longer than the "MAXRECSIZE" of the
      designated B6700 file, then we close the data connection, issue a
      reject message, and abort the local (B6700) transfer process.  If
      a record of incoming data is shorter than the specified MAXRECSIZE
      of the file, then the record is filled-out with blanks in type-
      ASCII or with nulls (0) in type-Image.  With Image, of course,
      this applies only to the last record of the B6700 file.  As in
      standard-FTP, "F" is default.

私たちは「F」(ファイル)と「R」(記録)構造の両方を許します。 CRLFが線のEndとして使用されるところで記録構造はASCII/ストリームだけで重要です。 STORでRecord-構造を私たちに使用するとき、入って来る記録が指定されたB6700ファイルの"MAXRECSIZE"より長いなら、私たちは、データ接続を終えて、廃棄物メッセージを発行して、地方の(B6700)転送プロセスを中止します。 受信データの記録がファイルの指定されたMAXRECSIZEより短いなら、記録にタイプASCIIによる空白かタイプイメージによるヌル(0)で書き込まれます。 もちろん、Imageと共に、これはB6700ファイルに関する最後の記録だけに適用されます。 標準のFTPのように、「F」はデフォルトです。

(7)   ALLO

(7) 異

      We have taken the liberty with the FTP-protocol of using the
      "ALLO" command to enable the user to designate the B6700 "file-
      attributes" of his UCSD file.  The FTP-standard form of ALLO is
      ignored (i.e. "ALLO n", where 'n' is some integer), although a
      "200" response will be returned in this case.  Our "special" form
      is where the ALLO verb is immediately followed by a "#", which is
      in turn followed by a parenthesized list of standard B6700 file
      attributes as used on B6700 "label-equate" cards.  Following is an
      example of this usage;

私たちはユーザが彼のUCSDの「ファイル属性」がファイルするB6700を指定するのを可能にする「異」コマンドを使用するFTPプロトコルがある自由を取りました。 'ALLOのFTP標準形式が無視される、(すなわち、"ALLO n"、どこ、'、何らかの整数)、この場合「200」応答を返すでしょうが。 私たちの「特別な」フォームはB6700で同じくらい中古のB6700ファイル属性が「ラベルで等しくする」規格のparenthesizedリストが順番にあとに続く「#」カードがすぐにALLO動詞を支えるところです。 以下に、この用法に関する例があります。

            ALLO #(KIND=TAPE9,MAXRECSIZE=10,MYUSE=OUT,TITLE=XYZ)

異#(種類はTAPE9と等しく、MYUSE=が外にあるMAXRECSIZE=10はタイトル=XYZです)

      If this form of the ALLO command is not given prior to a STOR,
      then the file will have the name given prior in the STOR command
      and will have the same characteristics as a standard "CANDE"
      type-DATA disk file (i.e. where (MAXRECSIZE=14, BLOCKSIZE=420,
      AREAS=15, AREASIZE=450)).  If no special ALLO is given preceding a
      RETR, then the file attributes are those of the file itself as it
      exists on the disk and are not altered.  In cases where the
      special ALLO is given prior to a transfer, the name of the file is
      determined by the TITLE attribute and the name given as the
      pathname of the STOR or RETR command is ignored.  If no TITLE is

ALLOコマンドのこの書式がSTORの前に与えられないと、ファイルがSTORコマンドで名前を優先的に与えさせて、標準の"CANDE"タイプデータディスクファイルと同じ特性を持つ、(すなわち、どこ、(MAXRECSIZE=14、BLOCKSIZE=420、領域は15、AREASIZE=450と等しいです。) RETRに先行しながらどんな特別なALLOも与えないなら、ファイル属性をディスクの上に存在するときのファイル自体のものであり、変更しません。 特別なALLOが転送の前に与えられる場合では、ファイルの名前はSTORかRETRコマンドのパス名が無視されるので与えられたTITLE属性と名前で決定します。 どんなTITLEもそうでないなら

Merryman                                                        [Page 2]

RFC 532             The UCSD-CC Server-FTP Facility         12 July 1973

道化師[2ページ]RFC532UCSD-CCサーバFTP施設1973年7月12日

      specified in an ALLO, then the internal filename of "LOCALFILE" is
      used.  With the "file-attribute-list" form of the ALLO command,
      the user has much of the same liberty to govern file
      characteristics as he does in using a "label-equate" card with a
      normal B6700 job.  For information concerning the available file
      attributes and their possible values, please contact the UCSD-CC
      consultant.  Additionally, you must remember that when doing a
      STOR to a tape at UCSD, you must specify MYUSE=OUT in the file-
      attribute list of the ALLO command.  Also, when transferring to or
      from tapes at UCSD, you must make prior arrangements with our
      operators (over TELNET) to locate and mount the tape.  We will
      soon implement a means whereby you may communicate with the
      operators directly through FTP.

ALLOで指定されていて、そして、"LOCALFILE"の内部のファイル名は使用されています。 ALLOコマンドの「ファイル属性リスト」フォームがあるので、ユーザは彼が通常のB6700仕事がある「ラベルで一致した」カードを使用する際に持っているようにファイルの特性を決定する同じ自由の多くを持っています。 利用可能なファイル属性とそれらの可能な値の情報に関しては、UCSD-CCコンサルタントに連絡してください。 さらに、あなたは、UCSDでテープにSTORをするとき、ALLOコマンドのファイル属性リストでMYUSE=OUTを指定しなければならないのを覚えていなければなりません。 また、テープかUCSDのテープから移すとき、あなたは、テープを場所を見つけて、取り付けるために私たちのオペレータ(TELNETの上の)と共に先の手配をしなければなりません。 私たちはすぐ、あなたがFTP直接を通してオペレータとコミュニケートできる手段を実装するつもりです。

(8)   XLINE

(8) XLINE

      This special command sets Record-structuring in our Server-FTP
      without the foreign user having to use a STRU R command (which may
      be rejected by his own host system).  This is specifically useful
      when transferring text files between UCSD and TENEX's (which do
      not implement Record-structuring) - i.e., if we are sending, we
      will append CRLF's to the end of each line of text (we do not
      store these in the file) and will store a line upon receiving data
      when a CRLF is seen, stripping the CRLF.  Entering "XLINE OFF"
      will restore File-structuring on our end.

この特別なコマンドはSTRU Rコマンド(彼自身のホストシステムによって拒絶されるかもしれない)を使用しなければならない外国人のユーザなしで私たちのServer-FTPにRecord-構造をはめ込みます。 UCSDとTENEXのもの(Record-構造を実装しない)の間にテキストファイルを移すとき、これは明確に役に立ちます--すなわち、発信するなら、私たちは、それぞれのテキスト行(私たちはファイルにこれらを保存しない)の端にCRLFのものを追加して、CRLFが見られるとデータを受け取るとき系列を保存するつもりです、CRLFを剥取って。 入る、「」 ウィルのXLINEは私たちの方でファイル構造を回復します。

(9)   RETR , STOR

(9) RETR、STOR

      As specified in standard-FTP except as modified by the "special"
      ALLO command (see part (7)).

「特別な」ALLOによって変更されるのを除いて、標準のFTPで指定されるように命令してください。(部分(7))を見てください。

(10)  APPE

(10) APPE

      Not implemented at this time, but will be in near future.

近い将来実装される以外に、このとき、実装されません。

(11)  DELE , RNTO , RNFR

(11) DELE、RNTO、RNFR

      Not implemented.  It is suggested that to perform these functions,
      the user log to our TELNET server ("CANDE"), invoke the "LIBMAINT"
      program (simply type LIBMAINT), and say;

実装されません。 これらの機能(私たちのTELNETサーバ("CANDE")へのユーザログ)が働くために、"LIBMAINT"プログラム(単に、LIBMAINTをタイプする)を呼び出して、言うことが提案されます。

            REMOVE file-name
                or
            CHANGE file-name-1 TO file-name-2

削除、ファイル名かCHANGEファイル名1のTOファイル名2

      Say BYE in order to exit LIBMAINT.

LIBMAINTを出るためにBYEを言ってください。

Merryman                                                        [Page 3]

RFC 532             The UCSD-CC Server-FTP Facility         12 July 1973

道化師[3ページ]RFC532UCSD-CCサーバFTP施設1973年7月12日

(12)  ABOR, BYE

(12) ABOR、さようなら

      As specified in standard-FTP; except that, until further notice, a
      BYE given while a transfer is in progress will not be queued for
      action following the transfer.

標準のFTPで指定されるように。 それ以外に、転送に続いて、追って通知があるまで、転送が進行している間に与えられているBYEは動作のために列に並ばせられないでしょう。

   Any commands not mentioned above are not yet implemented.

上に言及されなかった少しのコマンドもまだ実装されていません。

          [This RFC was put into machine readable form for entry]
    [into the online RFC archives by Helene Morin, Via Genie, 12/1999]

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

Merryman                                                        [Page 4]

道化師[4ページ]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

ログイン中のメンバーID

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る