RFC491 What is "Free"?

0491 What is "Free"?. M.A. Padlipsky. April 1973. (Format: TXT=5872 bytes) (Status: UNKNOWN)

日本語訳
RFC一覧

参照

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


                              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:

      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.

         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).

   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



Padlipsky                                                       [Page 1]

RFC 491                       What Is Free                 12 April 1973


   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?

   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.

   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.

   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.


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





Padlipsky                                                       [Page 2]

一覧

 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 

スポンサーリンク

INSTR関数 文字列中の文字列を検索する

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

上に戻る