rfc555.txt

RFC 相关的技术文档

Network Working Group                               James E. White (JEW)
Request for Comments: 555                                        SRI-ARC
NIC: 17993                                                 July 27, 1973


          Response to Critiques of the Proposed Mail Protocol

   A number of people have responded to my proposal for a Mail Protocol
   (JEW RFC 524 -- 17140,2:y).  In the current RFC, I've attempted to
   collect and respond to the questions, complaints, and suggestions
   that various individuals in the Network community have offered.  I
   intend to critique myself in a forthcoming RFC.

   I hope that dialog on the protocol proposal will continue, and that
   others will join in the discussion.  I will respond via RFC to any
   additional critiques I receive (I hope there'll be many).

I.  QUESTIONS

   HOW DOES THE SERVER VERIFY AN ID?

      References:

         (DHC JBP RFC 539 -- 17644,3g:gy)

      Discussion:

         One postulates the existence of AT LEAST ONE host whose Mail
         server process implements the User Verification Function (JEW
         RFC 524 -- 17140,5f7:gy).  Any process can contact that server,
         give him the name of any Individual in the Net and a test Id,
         and the server will determine whether or not the Individual and
         Id agree.

            The NIC, for one, will without question provide this
            service.

         With such support available to it, ANY FTP server process can
         then require (of any or all user processes that contact it) an
         ID command wherever it wishes within the user-server
         interchange (within the constraints of the Protocol).  The
         server simply prompts for the Id, gets it, opens a connection
         to the User Verification Agent, presents to it the Individual's
         name and purported Id, receives a positive or negative
         response, and deals with the original user process accordingly.






White                                                           [Page 1]

RFC 555     Response to Critiques of Proposed Mail Protocol    July 1973


         Example:

            Suppose a user process opens a connection to UCLA-NMC's
            server process, invokes the Delivery function, and in the
            course of the interchange identifies the Author as Roberts
            at USC-ISI.

            The implementors at UCLA-NMC's server process chose to
            require proof, in all Delivery transactions, that the Author
            is who he claims he is.  It therefore prompts for an Id in
            response to the AUTHOR command from the user process, and
            receives in return the command 'ID arpawheel <CA>'.

            UCLA-NMC's server then connects to the NIC's server, invokes
            the User Verification function there, specifying 'REQUESTOR
            roberts @ usc-isi <CA>' and 'ID arpawheel <CA>'.  The NIC
            informs UCLA-NMS that the Id is incorrect.

            UCLA-NMC then rejects the original ID command.

         Of course, the Protocol does not require that a server demand
         Ids from users that contact it.  Servers who choose not to
         require proof of identity simply never prompt for ID commands,
         and treat any they receive as NOPs.  For such implementations
         (which represent the current, FTP mail protocol situation), no
         third-part interchanges are ever required.

         Each user in the Net has a single Id that he uses throughout
         the Net for purposes of sending and receiving mail.  That Id
         need not (but may, either coincidentally or by design) have any
         other use.  In particular, a user's Id is independent of the
         passwords by which he gains access to accounts that he might
         possess on hosts around the Net.

            Of course, a user could and might see to it that his
            passwords and Id are the same.  The NIC, for example, might
            require that a user log in to its system with NIC ident and
            Id, rather than with host name and password, as it does
            currently.

         I emphasize again that Ids have nothing whatsoever to do with
         accounting.  UCLA-NMC doesn't force the Author to prove his
         identity so UCLA has someone to whom it can bill the resources
         consumed in processing the Delivery transaction.  It does so to
         prevent Jim White from authoring a piece of mail and claiming
         that Larry Roberts wrote it.





White                                                           [Page 2]

RFC 555     Response to Critiques of Proposed Mail Protocol    July 1973


            UCLA-NMC does have the option of requiring that a user
            process log in before it delivers mail so that it can be
            billed for the resources it uses.  The appropriate commands
            to require of the user process are USER, PASS, and ACCT.
            But, the billing process is separable from that of
            identifying Author, Clerk, etc.

            The NIC, for example, in its role as a Distribution Agent,
            might establish an account at UCLA-NMC to use whenever it
            delivers mail there.  UCLA-NMC will bill ALL of the NIC's
            activity at UCLA to that account.  But when the NIC delivers
            a piece of mail it claims was authored by Larry Roberts,
            UCLA-NMC may still wish to verify that claim.  Hence the ID
            command.

   ACK, PROGRESS REPORT, OR REPLY WITH NO REFERENCE SERIAL NUMBER

      References:

         (DHC JBP RFC 539 -- 17644,3h:gy)

      Discussion:

         A Delivery of type POSITIVE or NEGATIVE ACKNOWLEDGMENT,
         PROGRESS REPORT, or REPLY requires a Reference Serial Number of
         the user process.  Should the server determine that one is
         lacking when the final EXIT command is given, he should reject
         the EXIT command with an appropriate error response.

            The same applies in the Distribution function:  a Reference
            Serial Number MUST be specified if the Delivery Type is
            REPLY.

         The Protocol document is deficient in that it doesn't state the
         above.

II.  COMPLAINTS

   TERMINATING BOTH THE SUBSYSTEM AND FUNCTIONS WITH EXIT

      References:

         (AAM -- 17404,)








White                                                           [Page 3]

RFC 555     Response to Critiques of Proposed Mail Protocol    July 1973


      Discussion:

         I have no objection to defining two terminating commands, one
         to exit a function, the other to exit the subsystem.  I guess
         I'd suggest defining a command 'GO <CA>' to be used to
         terminate a function.

         I don't believe, however, that's it's necessary to distinguish
         the two cases to avoid confusion by human users.

         Even though the command language is ASCII, rather than binary,
         and even though I've adopted Mike Padlipsky's concept of a
         Unified USER Level Protocol', I don't consider that MP is a
         protocol for direct use by humans (although nothing can STOP a
         human user from speaking MP if he has access to a TELNET user
         program and is determined to do so).

         The concept I mean to extract from the UULP and exploit is its
         model of a single process with many subsystems, not its
         philosophy of a Network-standard command language for use by
         human users (the latter may be a good idea, too, but it's not
         the one I'm concerned with at the moment).

         I don't think that designing a protocol to govern an exchange
         between processes is the same task as designing a protocol to
         mediate a conversation between a process and a human user.
         Using ASCII commands suggests (as it did for FTP, RJE, etc.)
         that the latter problem is the one being addressed; it's not.

   USING TELNET GO AHEAD TO TERMINATE CERTAIN COMMANDS

      References:

         (AAM -- 17404,)

         (RCC -- 17822,1a:gy)

         (DHC JBP RFC 539 -- 17644,3b:gy)

      Discussion:

         Agreed.  My mistake.

         I simply have a strong distaste for the current FTP convention
         of terminating commands whose argument may itself contain CR LF
         with 'CR LF . CR LF'.  That seems a little extravagant to me.
         Personally, I'd prefer a single NVT character as a delimiter.




White                                                           [Page 4]

RFC 555     Response to Critiques of Proposed Mail Protocol    July 1973


         <CA2> only terminates two MP commands (COMMENTS and TEXT).
         Some NVT character (ESC? EXT? ...) can easily be chosen that
         need not appear (and can therefore be prohibited from appearing
         by the Protocol) in the argument to either of those commands.

   SUBSYSTEM OR SEPARATE RJE-LIKE SERVER PROCESS

      References:

         (DHC JBP RFC 539 -- 17644,4a:gy)

         (AAM -- 17404,)

         (ADO RFC 552 -- 17809,3:y)

      Discussion:

         There are two separable issues here:

            (1)  Server Process Proliferation of Not?

               If the consensus of the Network community is that
               Padlipsky's UULP approach to protocol design and
               implementation is in fact superior to the current scheme,
               which calls for the implementation of each new Network
               protocol as a distinct server process with its own
               contact socket, then we should begin to embrace that
               concept and begin reshuffling existing protocol
               implementations accordingly.  Even more surely, NEW
               protocols (like MP), should be designed in accordance
               with the new standards, not the old.

               I think Buz Owen's suggestion (ADO RFC 552 -- 17809,3:y)
               -- that a skeletal UULP be defined, a socket assigned to
               server processes which implement it, and MP defined as a
               subsystem under it -- is excellent.  I retract my
               suggestion (JEW RFC 524 -- 17140,3a2:gy) in favor of
               Owen's.

               I further suggest that the latest revision of FTP (NJN
               RFC 542 -- 17759,) be similarly implemented (i.e., as a
               UULP subsystem), rather then implemented temporarily
               under a new socket and later moved over to socket 3 as
               suggested in RFC 542.







White                                                           [Page 5]

RFC 555     Response to Critiques of Proposed Mail Protocol    July 1973


            (2)  RJE's model for FTP Use or Not?

               If both MP (as currently defined) and RJE were instated
               as UULP subsystems, they would still embrace different
               philosophies regarding their use of FTP.  As the person
               who proposed and fought for the current RJE model (i.e.,
               to its use of FTP),  I (still) believe it to be an
               elegant one, more elegant by far then the one I've
               proposed for MP.

               An alternative I considered and discarded SOLELY for
               reasons of efficiency (neglecting, perhaps, the issue of
               cleanness of implementation), is that the command
               currently defined as 'FILE <CA>' (JEW RFC 524 --
               17140,4q2a:gy), both in specifying Content and in the
               Citation Retrieval function, be 'FILE <fileaddr> <CA>'
               instead.

                  The server is then obliged to retrieve the Content of
                  the Mail from the designated server process via a
                  third-party exchange.

               The redefined FILE command would be similar to the
               LOCATION command, except that the former would specify