RFC479 日本語訳

Network Working Group                               James E. White (JEW)
Request for Comments:  479                                       SRI-ARC
NIC: 14948                                                 March 8, 1973

白の(JEW)がコメントのために要求するワーキンググループジェームスE.をネットワークでつないでください: 479 様アークNIC: 14948 1973年3月8日

                     Use of FTP by the NIC Journal

NICジャーナルによるFTPの使用

   At the Network Mail Meeting (see -- 14317,) the NIC outlined it's
   requirements for implementing FTP Journal delivery and submission.

NetworkメールMeeting、(見る、--14317、)、NICはFTP Journalが配送と服従であると実装するためのそれの要件について概説しました。

   It had always been our thinking that those two services should rely
   upon the File Transfer Protocol's MLFL command for their
   implementation.

それは私たちが、いつもそれらの2つのサービスがそれらの実装のためにFile TransferプロトコルのMLFLコマンドを当てにされるべきであると考えたことです。

   Prior to the meeting, we had envisioned that, in the case of
   submission, for example, the user would embed what parameters the NIC
   required (e.g., an indication that this piece of mail was to be
   journalized, a list of NIC idents, etc.) in the USERNAME field of the
   MLFL command, in a way that was transparent to his FTP user process,
   and that SRI-ARC's FTP server process would parse the 'user name' for
   the parameters and internally invoke the Journal System with them and
   the text of the mail as arguments.

ミーティングの前に、私たちは服従の場合でそれを思い描きました、例えば、ユーザがNICが必要としたすべてのパラメタ(例えば、このメールが仕訳されることであったという指示、NIC identsのリストなど)をMLFLコマンドのUSERNAME分野に埋め込むでしょう、彼のFTPユーザ・プロセスに見え透いた方法で、そして、そのSRI-ARCのFTPサーバプロセスがパラメタのために'ユーザ名'を分析して、議論としてそれらとメールの原本で内部的にJournal Systemを呼び出すでしょう。

      Our goal (which this scheme would have satisfied) was to provide
      the desired services while confining software changes to our own
      system and, in particular, to avoid requiring that user FTP
      processes or the File Transfer Protocol itself be modified.

私たちの目標(この体系が満たしただろう)は変更されていて、ソフトウェアを限定するのが私たち自身のシステムに変化して、そのユーザFTPを必要とするのを避けるのを特に処理される間の必要なサービスかFile Transferプロトコル自体を提供することでした。

   It was, however, the consensus of those present at the meeting that
   it was preferable to modify FTP in such a way that all required
   parameters could be explicitly declared, rather than require that
   they be hidden within what purported to be simply a user name.

しかしながら、それはそれらが単にユーザ名であることを意味したことの中に隠されるのが必要であるというよりもすべての必要なパラメタが明らかにむしろ宣言されるかもしれないような方法でFTPを変更するのが望ましかったというミーティングに出席しているそれらのコンセンサスでした。

   The intent of this RFC is to list what we (the NIC) believe were the
   new FTP commands it was agreed should be defined in support of mail
   submission and delivery. Actually, we've done some massaging after
   thinking about the issues for awhile, and so this is really a
   description of what we'd like to see included in the File Transfer
   Protocol (following the lines of thought which developed at the
   meeting), along with a short description of how the NIC would use
   them.

このRFCの意図は私たち(NIC)が新しいFTPが、メール提案と配送を支持して定義されるべきであるのに同意されたと命令するということであったと信じていることを記載することです。 しばらく問題について考えた後に実際に、私たちがいくつかのマッサージをしたので、これは本当にFile Transferプロトコルに含まれている見たいと思うものに関する記述(ミーティングで展開した考えについてその線でいく)です、NICがどうそれらを使用するだろうかに関する短い記述と共に。

   Some of the commands currently make sense only if issued TO the NIC's
   FTP server process (as opposed to anybody else's) and others only if
   issued BY the NIC's FTP user process (as opposed to anybody else's).
   This is true because currently only the NIC plans to offer mail

TO NICのFTPサーバプロセス(他の誰かと対照的に)と他のものに発行される場合にだけ、BY NICのFTPユーザ・プロセス(他の誰かと対照的に)を発行する場合にだけ、コマンドのいくつかが現在、理解できます。 現在のNICだけが、メールを提供するのを計画しているので、これは本当です。

White                                                           [Page 1]

RFC 479              Use of FTP by the NIC Journal            March 1973

NICジャーナル行進1973年までにFTPの白い[1ページ]RFC479使用

   forwarding and recording (i.e., the Journal System) as a service.
   However, other hosts may in the future desire to implement a similar
   service, at which time these special commands will have wider use.

サービスとして(すなわち、Journal System)を進めて、記録します。 しかしながら、他のホストはどの時に、これらの特別なコマンドにより広い使用があるかとき同様のサービスを実装する今後の願望でそうするかもしれません。

   Conceptually, all of these commands are sub-commands of a new MAIL
   command, but the intent for the moment is not to define their
   position within the FTP dialogue nor their syntax, but simply to
   describe them conceptually.  Details of syntax and use are left to
   the FTP Interest Group which meets 16-MAR-73 in Boston (see --
   14333,).

しかし、概念的に、これらのコマンドのすべてが新しいメールコマンドのサブコマンドですが、さしあたりの意図がFTP対話の中で彼らの立場を定義しないことである、または、それらの構文、単に概念的にそれらについて説明するために。 構文と使用の詳細はボストンで16 3月の73に会うFTP Interest Groupに残されます。(見てください--、14333、)

   The new sub-commands are described below.  Bracketed fields are
   optional; slash denotes a choice of two or more alternatives.

新しいサブコマンドは以下で説明されます。 腕木を付けられた分野は任意です。 スラッシュは2つ以上の選択肢の選択を指示します。

      (1)  TITLE title

(1) TITLEタイトル

         Where 'title' is a character string describing for the human
         reader the contents of the mail.

'タイトル'が人間の読者のためにメールのコンテンツについて説明する文字列であるところ。

      (2)  USER-READABLE-AUTHOR author

(2)USER-READABLE-AUTHOR作者

         Where 'author' identifies the author of the mail to the human
         reader.  This may be a nickname, or any other identifier with
         which the human sender chooses to sign his mail.

'作者'が人間の読者にメールの作者を特定するところ。 これは、あだ名、または人間の送付者が彼のメールに署名するのを選ぶいかなる他の識別子であるかもしれません。

      (3)  PROCESS-READABLE-AUTHOR last, first initial (ident)

PROCESS-READABLE-AUTHORが最後、最初に頭文字をつける(3)(ident)

         Where the author's name (and ident if known) is made available
         to the server in a form it can hope to parse (if need be).

作者の名前(そして、知られているなら、identする)をフォームでサーバに利用可能にするところでは、それは、(必要なら、)分析することを望むことができます。

         This sub-command is important to the NIC, providing a basis for
         locating the author in the NIC's Ident files.

NICのIdentファイルで作者の居場所を見つける基礎を提供して、このサブコマンドはNICに重要です。

      (4)  FOR-ACKNOWLEDGMENT-AUTHOR username hostname

(4) FOR-ACKNOWLEDGMENT-AUTHORユーザ名ホスト名

         Where 'username' and 'hostname' define the sender in a way
         useful in acknowledging delivery (of forwarded mail).

'ユーザ名'と'ホスト名'がある意味で配送(転送されたメールの)を承諾する際に役に立つ送付者を定義するところ。

            The acknowledgment will itself be a piece of mail sent from
            the NIC to 'username' at 'hostname'.

承認は'ホスト名'でNICから'ユーザ名'に送られた1つのメールであるためにそれ自体で望んでいます。

         It's important, conceptually, to note the NIC's unique role
         here.  Normally, acceptance of the mail by the server would
         constitute acknowledgment of delivery.  But, in the case of
         Journal submission, the NIC acts only as a forwarding agent,
         and hence delivery of mail by the sender to SRI-ARC isn't

ここでNICのユニークな役割に注意するのは概念的に重要です。 通常、サーバによるメールの承認は配達承認を構成するでしょう。 しかし、Journal服従の場合では、NICは単に小口運送業者、およびしたがって、SRI-ARCへの送付者によるメールの配送のように行動します。

White                                                           [Page 2]

RFC 479              Use of FTP by the NIC Journal            March 1973

NICジャーナル行進1973年までにFTPの白い[2ページ]RFC479使用

         really delivery at all -- only submission.  Final delivery
         occurs when the NIC transmits a copy of the mail to each of its
         addressees; hence the need for this special kind of
         acknowledgment.

本当に全く配送--服従だけ。 NICがメールのコピーを受け取り人各人に送るとき、最終的な配送は起こります。 したがって、この特別な種類の承認の必要性。

         Note that this sub-command and the previous two constitute
         different renderings of the sender's name.

このサブコマンドと前の2が送付者の名前の異なったレンダリングを構成することに注意してください。

      (5)  ACKNOWLEDGMENT-DETAILS
             DEFAULT / (COMPLETION / FAILURE / PERIODIC interval
                        GIVEUP time
                        TERSE / VERBOSE)

(5) 承認詳細デフォルト/(COMPLETION/FAILURE/PERIODIC間隔GIVEUP時間TERSE / VERBOSE)

         The value of the first parameter (ignoring 'DEFAULT' for the
         moment) determines the conditions under which acknowledgment
         will be made to the sender:

最初のパラメタ(さしあたり、'DEFAULT'を無視する)の値は承認が送付者に作られている状態を決定します:

            -- upon completion, whether delivery was successful or timed
            out for one or more addressees,

-- 完成、配送がうまくいったか、1のための外で調節されたか、そして、または、より多くの受け取り人で

            -- only if delivery failed for one or more addressees, or

-- または配送が1人以上の受け取り人に失敗した場合にだけ。

            -- periodically until delivery is complete.

-- 定期的である、配送が完全になるまで。

         The value of the second parameter determines the time after
         which delivery attempts will be discontinued.

2番目のパラメタの値は配送試みが中止される時を決定します。

         The value of the third parameter determines how detailed -- in
         some as yet unspecified sense -- an acknowledgment will be
         returned.

3番目のパラメタの値は、まだ不特定の感覚としてのいくつかで詳しく述べられて、承認がどのように返されるかを決定します。

            A verbose acknowledgment might, in the case of delivery
            failure, include a copy of the text of the message, or, for
            mail sent by citation (see item 10 below), a pointer to it.

または、冗長な承認は引用(以下の項目10を見ます)(それへの指針)で送られたメールのために配信障害に関するケースにメッセージの本文のコピーを含むかもしれません。

         If DEFAULT is specified (in which case, FOR-ACKNOWLEDGMENT-
         AUTHOR should not be specified, and 'DEFAULT' applies to it,
         too), the NIC will extract a set of default values from its
         Ident files, provided that a PROCESS-READABLE-AUTHOR subcommand
         is present and the sender's NIC Ident can be inferred from it;
         otherwise, the NIC will apply a set of (as yet unspecified)
         system defaults.

DEFAULTが指定されると(その場合、FOR-ACKNOWLEDGMENT- AUTHORを指定するべきではありません、そして、また、'DEFAULT'はそれに適用します)、NICはIdentファイルから1セットのデフォルト値を抽出するでしょう、PROCESS-READABLE-AUTHORサブコマンドが存在していて、それから送付者のNIC Identを推論できれば。 さもなければ、NICは1セットの(まだ不特定)のシステム・デフォルトを適用するでしょう。

            The NIC's Ident files will be modified to contain, for each
            user known to it, the kind of acknowledgment the user
            usually wants (i.e., his default) and the username and
            hostname that define the destination for such
            acknowledgments.  These last two pieces of information will

NICのIdentファイルは、それに知られている各ユーザのためにそのような承認のために目的地を定義する通常、ユーザが欲しい承認の種類(すなわち、彼のデフォルト)、ユーザ名、およびホスト名を含むように変更されるでしょう。 2つの情報はそうするでしょう。

White                                                           [Page 3]

RFC 479              Use of FTP by the NIC Journal            March 1973

NICジャーナル行進1973年までにFTPの白い[3ページ]RFC479使用

            also be used in delivering mail to the user if he has
            requested Network delivery (as opposed to Online (at the
            NIC) or hardcopy).

また、彼がNetwork配送(Online(NICの)かハードコピーと対照的に)を要求したならメールをユーザに提供する際に使用されてください。

      (6)  ADDRESSEES-ARE name1, name2, ...

(6)、ADDRESSEES存在、name1、name2…

         This sub-command identifies the recipient(s) of the mail.  In
         general, 'namei' will be the name by which the recipient is
         known locally in the server's system.

このサブコマンドはメールの受取人を特定します。 一般に、'namei'は受取人がサーバのシステムで局所的に知られている名前になるでしょう。

         The NIC's server FTP process will permit 'namei' to be any of
         the following:

NICのサーバFTPプロセスは、'namei'が以下のどれかであることを許可するでしょう:

            -- a NIC Ident (designating either an individual or a
            group),

-- NIC Ident(個人かグループのどちらかを任命します)

            -- username hostname, where 'username' is the name by which
            the addressee is known at host 'hostname', or

-- 'ユーザ名'が受け取り人がホスト'ホスト名で知られている名前であることのユーザ名ホスト名

            -- lastname, firstname initial , which the NIC will attempt
            to parse and then locate in its Ident files.

-- NICが分析して、次に、場所を見つけるのを試みるfirstname初期のlastnameはIdentにファイルされます。

         Note that now the possibility of multiple addressees is
         explicitly admitted by the Protocol, but the meaning of 'useri'
         (to the server) is left server-dependent.

現在、複数の受け取り人の可能性がプロトコルによって明らかに認められますが、'useri'(サーバへの)の意味がサーバ依存していた状態でおかれることに注意してください。

      (7)  MAIL-CLASS
             BULK/POSTCARD
             SPECIAL-DELIVERY/FIRST-CLASS

(7)メールクラス大量/はがき速達郵便/ファーストクラスです。

         The first parameter makes a statement about the size of the
         mail, and the server may choose to use it to decide how and
         where to store he mail for the addressee.

最初のパラメタは声明をおよそメールのサイズにします、そして、サーバは彼が受け取り人に郵送する店へのどのように、どこかを決めるのにそれを使用するのを選ぶかもしれません。

         The second parameter makes a statement about the importance of
         the mail, and the server may choose to expedite delivery (e.g.,
         interrupt the user if he's logged in) for SPECIAL-DELIVERY
         mail.

2番目のパラメタはメールの重要性に関してステートメントを発表します、そして、サーバはSPECIAL-DELIVERYメールのために配送を速めるのを(例えば、彼がログインしたなら、ユーザを遮ります)選ぶかもしれません。

      (8)  RECORD [identifier] [miscellaneous]

(8) 記録[識別子][その他]

         This is the command to the server to record the mail.
         'Identifier' allows the sender the option of specifying a pre-
         assigned identifier if he has one; if this field is not
         present, the server assigns one.

これはメールを記録するサーバへのコマンドです。 '識別子'は彼に1つがあるならあらかじめ割り当てられた識別子を指定するオプションを送付者に許容します。 この分野が存在していないなら、サーバは1つを割り当てます。

         'Miscellaneous' includes any server-dependent parameters which
         the server may require or allow.

'その他'はサーバが必要である、または許容するどんなサーバ依存するパラメタも含んでいます。

White                                                           [Page 4]

RFC 479              Use of FTP by the NIC Journal            March 1973

NICジャーナル行進1973年までにFTPの白い[4ページ]RFC479使用

         When this command is issued to the NIC, it will be taken as a
         command to Journalize the mail, and 'identifier' may be:

このコマンドをNICに発行するとき、aがJournalizeにメールを命令するとき、それを取るでしょう、そして、'識別子'は以下の通りです。

            NIC number [RFC number]

NIC番号[RFC番号]

         The NIC may allow 'miscellaneous' to contain such information
         as comments, keywords, etc.

NICは'その他'にコメントするような情報、キーワードなどを含ませるかもしれません。

      (9)  PRESERVED-AT hostname AS identifier

(9) PRESERVED-ATホスト名AS識別子

         This is not a command but a statement of fact which the FTP
         server will presumably relay to the user as it does the
         information contained in (for example) the TITLE command.

(例えば、)TITLEコマンドに含まれた情報をするとき、これはコマンドではなく、おそらく、FTPサーバがユーザにリレーする事実の声明です。

         The implication is that a copy of this piece of mail has been
         preserved at 'hostname' and is retrievable -- on a long-term
         basis -- with 'identifier'.  'Identifier' might, in general, be
         a pathname.

含意は、このメールのコピーが'ホスト名'で保存されたということであり、'識別子'で長期ベースで回収可能です。 一般に、'識別子'はパス名であるかもしれません。

         When the NIC delivers Journal articles through the Net, it will
         include this sub-command, and 'identifier' will be a NIC
         number, and 'hostname' of course 'SRI-ARC' or 'NIC'.

'識別子'は、NICがネットを通して記事をJournalに提供するとき、このサブコマンドを含んで、NIC番号と、'になるでしょうもちろん'SRI-ARC'か'NIC'という'ホスト名。

      (10) TEXT text
           FILE pathname hostname

(10) TEXTテキストFILEパス名ホスト名

         One of these two sub-commands is used to actually transmit the
         mail:  the first transmits the text of the mail, the second a
         pointer to it (leaving open to the FTP server (or his user) the
         option of retrieving the text of the mail from the specified
         host).

これらの2つのサブコマンドの1つは実際にメールを伝えるのに使用されます: 1番目はメールの原本を伝えて、秒はそれへの指針(指定されたホストからFTPサーバ(または、彼のユーザ)に開かれていた状態でメールの原本を検索するオプションを外して)です。

         The NIC will transmit mail created within NLS with 'Submit
         File' using the FILE command, and mail created with 'Submit
         Message' using the TEXT command.   For mail entering the SRI-
         ARC system via its FTP server process, the NIC will employ the
         same command in delivery as was used in submission.

NICは'Fileを提出してください'がFILEコマンドを使用して、'Messageを提出してください'がTEXTコマンドを使用している状態でメールが作成されている状態でNLSの中で作成されたメールを伝えるでしょう。 FTPサーバプロセスを通してSRI- ARCシステムを入れる郵便配達人に関しては、NICは服従に使用された配送における同じコマンドを使うでしょう。

       [ This RFC was put into machine readable form for entry ]
      [ into the online RFC archives by Hannes Faestermann 12/97 ]

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

White                                                           [Page 5]

ホワイト[5ページ]