RFC491 日本語訳

Network Working Group                                    M. A. Padlipsky
Request for Comments: 491                                    MIT-Multics
NIC: 15356                                                 12 April 1973

A.Padlipskyがコメントのために要求するワーキンググループM.をネットワークでつないでください: 491MIT-Multics NIC: 15356 1973年4月12日

                              What Is Free

無料であることのこと

   In at least three of the RFC's about "mail" and the File Transfer
   Protocol (RFC's 454, 475, 479), something very like the following is
   asserted: "Network mail should be free; i.e., no login or USER
   command should be required."  Unfortunately, "i.e" (=that is) is
   misleading.  It simply does not follow to imply that the only way
   mail can be free is for it not to require a login; explicit login on
   a free account would of course also work.  Indeed, depending upon
   per-Host idiosyncrasies in the Logger / Answering Service / process
   creation environment, an explicit login may well prove to be far more
   natural than an implicit login.  (Even in environments where implicit
   login is easy, surely explicit login is just easy.)  Granted, login
   on a free account requires users to remember the name of the free
   account.  However, this would not be too great a burden to bear if
   there were reasons for preferring an explicit login and if the free
   account had the same name on all Hosts.  Therefore, from the promise
   that Network protocols should not implicitly legislate "unnatural"
   implementations for participating Hosts if it is conveniently
   avoidable, I propose the following formulation:

少なくとも3RFCが中では、「メール」とFile Transferプロトコルに関するものです。(RFCの454、475、479)、以下のように何かまさしくそのものは断言されます: 「ネットワークメールは無料であるべきです」。 「すなわち、どんなログインもUSERコマンドも必要とするべきではありません。」 残念ながら、「i.e」(= すなわち)は紛らわしいです。 絶対にメールが無料である場合がある唯一の方法がログインを必要としないつもりであることであるということになりません。 また、無料のアカウントにおける明白なログインはもちろん働いているでしょう。 本当に、Logger/回答のService/過程創造環境における1ホストあたりの特異性によって、明白なログインはたぶん暗黙のログインよりはるかに自然であると判明するでしょう。 (暗黙のログインが簡単である環境でさえ、確実に、明白なログインはただ簡単です。) 与えて、無料のアカウントにおけるログインは、ユーザが無料のアカウントの名前を覚えているのを必要とします。 しかしながら、明白なログインを好む理由があって、無料のアカウントがすべてのHostsに同じ名前を持っているなら、これは持っている大き過ぎる負担でないでしょうに。 したがって、それが便利に回避可能であるならNetworkプロトコルが参加Hostsのためにそれとなく「不自然な」実現を制定するべきでないという約束から、私は以下の定式化を提案します:

      Network mail should be free.  Network mail should not require
      users to remember the name of the free account on a given system.
      I.e., it should either be "loginless" or it should take the same
      login everywhere.  But some systems need/want/prefer a login.
      Therefore, USER NETML / PASS NETML should be made to work
      everywhere for free mail.

ネットワークメールは無料であるべきです。 ネットワークメールは、ユーザが与えられたシステムで無料のアカウントの名前を覚えているのを必要とするべきではありません。 すなわち、それは"loginless"であるべきですかそれはいたる所で同じログインを取るべきです。 しかし、いくつかのシステムが、ログインを必要である、欲しい、または好みます。 したがって、USER NETML / PASS NETMLは無料のメールのためのいたる所で働かされるべきです。

         Note: "NETML" is fewer than six characters and is upper case
         hence, it should fit in the least common denominator category
         of user identifiers, but it's still long enough not to conflict
         with anybody's initials (in all probability).

以下に注意してください。 "NETML"が6つ未満のキャラクタであり、したがって、大文字である、ユーザ識別子の共通項カテゴリをうまくはめ込むべきですが、それはまだだれのイニシャル(きっと)とも衝突しないほど長いです。

   Now, because of the implementation implications this may all sound
   like special pleading, but I claim that another implication of the
   "incorrect" formulation will further show the superiority of an
   explicit login for mail.  For the "loginless" view leads to problems
   in regard to the authentication aspects of login and the accounting
   aspects, by apparently assuming that the sole purpose of login is to
   initiate accounting.  In RFC 475, the problem is exposed when, after
   noting that some systems allow access control to be applied to
   mailboxes, it is asserted that FTP USER command is wrong for access
   control because you'd then be on the free account and a new FTP FROM

今、実現含意のために、これは特別訴答のようにすべて聞こえるかもしれませんが、私は、「不正確な」定式化の別の含意がさらにメールのための明白なログインの優越を示すと主張します。 "loginless"に関しては、ログインの唯一の目的が会計を開始することであると明らかに仮定することによって、ログインの認証局面と会計局面に関する問題として先導を見てください。 いくつかのシステムが、アクセス管理がメールボックスに適用されるのを許容することに注意した後にその時、あなたは無料のアカウントと新しいFTP FROMにいるでしょう、したがって、アクセス管理において、FTP USERコマンドが間違っていると断言されるとき、RFC475では、問題は露出されています。

Padlipsky                                                       [Page 1]

RFC 491                       What Is Free                 12 April 1973

Padlipsky[1ページ]RFC491、ことは1973年4月12日を解放することです。

   command would be right.  (Presumably, FROM would be followed by
   PASS.)  Being reasonably familiar with one of the systems which does
   allow access control on mailboxes, let me point out how it works:
   permissible "principal identifiers" are placed on the "access control
   list" of the mailbox, and when the mailbox is referenced by a process
   the principal identifier of that process must match (explicitly or as
   a member of a class) an entry on the list or access will be
   forbidden.  But the principal identifier is associated with the
   process at login.  Now, it is probably a valid objection to say that
   accounting should be separated from authentification, but it isn't
   always.  So why invent a redundant mechanism based on the assumption
   that it is?

コマンドは正しいでしょう。 (おそらく、FROMはPASSによって続かれるでしょう。) 合理的にメールボックスの上にアクセス管理を許容するシステムの1つになじみ深くて、どう働いているかを指摘させてください: 許されている「主要な識別子」はメールボックスの「アクセスコントロールリスト」に置かれます、そして、工程でメールボックスが参照をつけられるとき、その過程の主要な識別子がリストの上のエントリーに合わなければならない(明らかかクラスのメンバーとして)、さもなければ、アクセスは禁じられるでしょう。 しかし、主要な識別子はログインにおける過程に関連しています。 現在、会計が認証と切り離されるべきであると言うのが、たぶん有効な異論ですが、それはいつもそのような異論であるというわけではありません。 それで、なぜ仮定に基づく余分なメカニズムを発明しますか?

   Another point on authentication via login: it has been argued that
   FTP mail ought to be so cheap that it "can be buried in overhead" by
   the same token, if it's so cheap it shouldn't bother anybody to login
   on his own account if he wants to prove the mail's from himself.

ログインを通した認証のもう1ポイント: FTPメールがとても安くあるべきであるので同じ象徴でそれを「オーバーヘッドでは、埋めることができる」と主張されました、自前で彼が、メールが自分から来ていると立証したいなら非常に安くて、ログインするようにだれにも苦しめないなら。

   To be scrupulous, I should close by mentioning the possibility that
   NETML might be repugnant to some Hosts.  If such be the case, then I
   propose that a new FTP FREE command be introduced so that Servers
   need not recognize MAIL as an implicit login.  The reasons here are
   at least twofold: First, it appears that when the "subcommands" to
   MAIL get worked out, some of them will have to precede the MAIL (or
   users will set awfully tired of typing their names, etc.); therefore,
   the list of commands which imply a login grow and grow and Server
   FTP's will have to change and change.  Second, if MAIL implies a
   login, it will be hard in some environments to get the arguments
   across to the process created on behalf of the mailer (and it is not
   a good idea at all to assume that the mailing can be handled by the
   process which is listening on socket 3).  Even introducing a new
   mechanism (and see RFC 451 for my strong feelings against that sort
   of step in general) in FREE seems better than making all the
   assumptions that the loginless alternative does.

きちょう面に、なるように、私はNETMLがいくつかのHostsにいとわしいかもしれない可能性について言及することによって、閉じるべきです。 そして、そのようなものがケースであるなら、私は、Serversが、メールが暗黙のログインであると認める必要はないように新しいFTP無料コマンドが紹介されるよう提案します。 ここの理由は少なくとも二つです: まず最初に、メールへの「サブコマンド」が解決されるとき、彼らの何人かがメールに先行しなければならないように(ユーザは彼らの名前などをタイプするのにとても疲れていた状態でセットするでしょう)見えます。 したがって、ログインが成長して、成長するのを含意するコマンドとServer FTPのリストは、変化して、変化しなければならないでしょう。 2番目に、メールがログインを含意すると、いくつかの環境で、郵送者を代表して作成された過程に議論について説明しにくいでしょう(ソケット3の上に聴かれている工程で郵送を扱うことができると仮定するのは、全く名案ではありません)。 無料で新しいメカニズム(一般に、それに対する私の強い意見のためのRFC451がちょっと踏むのを見る)を紹介さえする、loginless代替手段がするようにすべての仮定をそれにするよりよく思えます。

   Note that an alternative to this whole line of reasoning would be
   simply to observe that the FTP is internally inconsistent in that it
   acknowledges on the one hand (in the definition of the USER command)
   that some systems may require USER / PASS and then (mis)states on the
   other hand (in the discussion of mail) that they may not.  If this
   abstract point is more satisfying to some readers than the foregoing
   pragmatic argument, well and good.

推理のこの全体の線への代替手段が一方では(USERコマンドの定義で)、いくつかのシステムがUSER / PASSとその時を必要とするかもしれないと認めるのでFTPが内部的に矛盾しているのを単に観測することであることに注意してください、(誤、)、他方では(メールの議論で)、彼らがそうしないかもしれないと述べます。 さて、この抽象的なポイントが以上の実践的な議論より何人かの読者に満足させられているならいいぞ。

          [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]

Padlipsky                                                       [Page 2]

Padlipsky[2ページ]