rfc944.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

Official ARPA-Internet Protocols                                 RFC 944


   Network Voice Protocol  ------------------------------------ (NVP-II)

      STATUS:  Experimental

      SPECIFICATION:  ISI Internal Memo

      COMMENTS:

         Defines the procedures for real time voice conferencing.

         The specification is an ISI Internal Memo which should be
         updated and issued as an RFC.

         Please discuss any plans for implementation or use of this
         protocol with the contact.

      OTHER REFERENCES:  RFC 741

      DEPENDENCIES:  Internet Protocol, Stream Protocol

      CONTACT:  [e-mail]

   Reliable Data Protocol  --------------------------------------- (RDP)

      STATUS:  Experimental

      SPECIFICATION:  RFC 908

      COMMENTS:

         This protocol is designed to efficiently support the bulk
         transfer of data for such host monitoring and control
         applications as loading/dumping and remote debugging.  The
         protocol is intended to be simple to implement but still be
         efficient in environments where there may be long transmission
         delays and loss or non-sequential delivery of message segments.

      OTHER REFERENCES:

      DEPENDENCIES:  Internet Protocol

      CONTACT:  [e-mail]









Reynolds & Postel                                              [Page 11]



Official ARPA-Internet Protocols                                 RFC 944


   Internet Reliable Transaction Protocol  ---------------------- (IRTP)

      STATUS:  Experimental

      SPECIFICATION:  RFC 938

      COMMENTS:

         This protocol is a transport level host to host protocol
         designed for an internet environment.  While the issues
         discussed may not be directly relevant to the research problems
         of the DARPA community, they may be interesting to a number of
         researchers and implementors.

      OTHER REFERENCES:

      DEPENDENCIES:  Internet Protocol

      CONTACT:  [e-mail]
































Reynolds & Postel                                              [Page 12]



Official ARPA-Internet Protocols                                 RFC 944


APPLICATION LEVEL

   Telnet Protocol  ------------------------------------------- (TELNET)

      STATUS:  Recommended

      SPECIFICATION:  RFC 854 (in "Internet Telnet Protocol and
      Options")

      COMMENTS:

         The protocol for remote terminal access.

         This has been revised since the IPTW.  RFC 764 in IPTW is now
         obsolete.

      OTHER REFERENCES:

         MIL-STD-1782 - Telnet Protocol

      DEPENDENCIES:  Transmission Control Protocol

      CONTACT:  [e-mail]




























Reynolds & Postel                                              [Page 13]



Official ARPA-Internet Protocols                                 RFC 944


   Telnet Options  ------------------------------------ (TELNET-OPTIONS)

      STATUS:  Elective

      SPECIFICATION:  General description of options:  RFC 855
      (in "Internet Telnet Protocol and Options")

      Number   Name                                RFC  NIC  ITP APH USE
      ------   ---------------------------------   --- ----- --- --- ---
         0     Binary Transmission                 856 ----- yes obs yes
         1     Echo                                857 ----- yes obs yes
         2     Reconnection                        ... 15391  no yes  no
         3     Suppress Go Ahead                   858 ----- yes obs yes
         4     Approx Message Size Negotiation     ... 15393  no yes  no
         5     Status                              859 ----- yes obs yes
         6     Timing Mark                         860 ----- yes obs yes
         7     Remote Controlled Trans and Echo    726 39237  no yes  no
         8     Output Line Width                   ... 20196  no yes  no
         9     Output Page Size                    ... 20197  no yes  no
        10     Output Carriage-Return Disposition  652 31155  no yes  no
        11     Output Horizontal Tabstops          653 31156  no yes  no
        12     Output Horizontal Tab Disposition   654 31157  no yes  no
        13     Output Formfeed Disposition         655 31158  no yes  no
        14     Output Vertical Tabstops            656 31159  no yes  no
        15     Output Vertical Tab Disposition     657 31160  no yes  no
        16     Output Linefeed Disposition         658 31161  no yes  no
        17     Extended ASCII                      698 32964  no yes  no
        18     Logout                              727 40025  no yes  no
        19     Byte Macro                          735 42083  no yes  no
        20     Data Entry Terminal                 732 41762  no yes  no
        21     SUPDUP                          734 736 42213  no yes  no
        22     SUPDUP Output                       749 45449  no  no  no
        23     Send Location                       779 -----  no  no  no
        24     Terminal Type                       930 -----  no  no  no
        25     End of Record                       885 -----  no  no  no
        26     TACACS User Identification          927 -----  no  no  no
        27     Output Marking                      933 -----  no  no  no
       255     Extended-Options-List               861 ----- yes obs yes

                                                        (obs = obsolete)

      The ITP column indicates if the specification is included in the
      Internet Telnet Protocol and Options.  The APH column indicates if
      the specification is included in the ARPANET Protocol Handbook.
      The USE column of the table above indicates which options are in
      general use.





Reynolds & Postel                                              [Page 14]



Official ARPA-Internet Protocols                                 RFC 944


      COMMENTS:

         The Binary Transmission, Echo, Suppress Go Ahead, Status,
         Timing Mark, and Extended Options List options have been
         recently updated and reissued.  These are the most frequently
         implemented options.

         The remaining options should be reviewed and the useful ones
         should be revised and reissued.  The others should be
         eliminated.

         The following are recommended:  Binary Transmission, Echo,
         Suppress Go Ahead, Status, Timing Mark, and Extended Options
         List.

      OTHER REFERENCES:

      DEPENDENCIES: Telnet

      CONTACT: [e-mail]

   File Transfer Protocol  --------------------------------------- (FTP)

      STATUS:  Recommended

      SPECIFICATION:  RFC 765 (in IPTW)

      COMMENTS:

         The protocol for moving files between Internet hosts.  Provides
         for access control and negotiation of file parameters.

         There are a number of minor corrections to be made.  A major
         change is the deletion of the mail commands, and a major
         clarification is needed in the discussion of the management of
         the data connection.  Also, a suggestion has been made to
         include some directory manipulation commands (RFC 775).

         Even though the MAIL features are defined in this document,
         they are not to be used.  The SMTP protocol is to be used for
         all mail service in the Internet.

         Data Connection Management:

            a.  Default Data Connection Ports:  All FTP implementations
            must support use of the default data connection ports, and
            only the User-PI may initiate the use of non-default ports.

            b.  Negotiating Non-Default Data Ports:   The User-PI may


Reynolds & Postel                                              [Page 15]



Official ARPA-Internet Protocols                                 RFC 944


            specify a non-default user side data port with the PORT
            command.  The User-PI may request the server side to
            identify a non-default server side data port with the PASV
            command.  Since a connection is defined by the pair of
            addresses, either of these actions is enough to get a
            different data connection, still it is permitted to do both
            commands to use new ports on both ends of the data
            connection.

            c.  Reuse of the Data Connection:  When using the stream
            mode of data transfer the end of the file must be indicated
            by closing the connection.  This causes a problem if
            multiple files are to be transfered in the session, due to
            need for TCP to hold the connection record for a time out
            period to guarantee the reliable communication.  Thus the
            connection can not be reopened at once.

               There are two solutions to this problem.  The first is to
               negotiate a non-default port (as in (b) above).  The
               second is to use another transfer mode.

               A comment on transfer modes.  The stream transfer mode is
               inherently unreliable, since one can not determine if the
               connection closed prematurely or not.  The other transfer
               modes (Block, Compressed) do not close the connection to
               indicate the end of file.  They have enough FTP encoding
               that the data connection can be parsed to determine the
               end of the file.  Thus using these modes one can leave
               the data connection open for multiple file transfers.

               Why this was not a problem with the old NCP FTP:

                  The NCP was designed with only the ARPANET in mind.
                  The ARPANET provides very reliable service, and the
                  NCP counted on it.  If any packet of data from an NCP
                  connection were lost or damaged by the network the NCP
                  could not recover.  It is a tribute to the ARPANET
                  designers that the NCP FTP worked so well.

                  The TCP is designed to provide reliable connections
                  over many different types of networks and
                  interconnections of networks.  TCP must cope with a
                  set of networks that can not promise to work as well
                  as the ARPANET.  TCP must make its own provisions for
                  end-to-end recovery from lost or damaged packets.
                  This leads to the need for the connection phase-down
                  time-out.  The NCP never had to deal with
                  acknowledgements or retransmissions or many other



Reynolds & Postel                                              [Page 16]



Official ARPA-Internet Protocols                                 RFC 944


                  things the TCP must do to make connection reliable in
                  a more complex world.

         LIST and NLST:

            There is some confusion about the LIST an NLST commands, and
            what is appropriate to return.  Some clarification and
            motivation for these commands should be added to the
            specification.

         Multiple 1xx Replies:

            There is some difference of opinion about the use of
            multiple 1xx responses during command processing.  This
            issue comes up particularly in processing the RETR and STOR
            commands.  The two opinions are summarized below.

            For Exactly One 1xx Response:

               When a RETR or SEND command is started, the server is
               supposed to give an "intermediate reply" of 1xx when it
               is opening the data connection.  Currently, some FTP
               servers give two 1xx messages.  This causes problems for
               single-thread FTP user implementations.  After reading
               the first intermediate reply, they go off to do the
               transfer.  The second 1xx message is not seen until the
               end of the transfer.  The RFC gives a state diagram of
               the form:

                  --------->Wait--------->
                          /      \
                          ^      |
                          |      V
                          \      /
                           <-----

               This implies any number of 1xx's (including 0).  There is
               a suspicion that this is just sloppy diagraming, and that
               the intent is clear from other parts of the RFC.

               The FTP specification states that the reason for
               intermediate replies is to allow implementations that
               can't do any better to know when to stop listening to the
               control channel and switch their attention to the data
               channel.  Given this intent, it seems clear that there
               should be exactly one 1xx reply at the start of the
               transfer.

               The FTP specification is ambiguous in this regard.  The


Reynolds & Postel                                              [Page 17]



Official ARPA-Internet Protocols                                 RFC 944


               state diagrams appear to sanction any number of
               responses.  But the charts before them do not.  And from
               the intent, it seems obvious that exactly one is the
               right thing.

               Consider an implementation on a PC.  It is fairly hard to
               do parallel processing there.  It should be possible for
               a PC implementation to stop paying attention to the
               control channel and start reading the file from the data
               channel when he sees the 1xx response.  The only way this
               can work is if there is only one 1xx response.

               Of course, one could make it a requirement that every FTP
               implementation must be based on good enough interrupt
               technology so that it can field extra responses during
               the transfer.  But what would such a constraint buy?
               Just the ability to have both a 125 and a 150 response.
               It doesn't seem worth the price.  You could just as well
               combine the information in those responses into a single
               one.

            For Multiple 1xx Responses:

               The multiple 1xx messages arose because the new TCP
               specification omitted the 050 spontaneous reply code.  A
               solution was to change an 050 informational message to a
               1xx message, creating both a 125 and a 150.

               The state diagrams clearly allow this, and the
               "Command-Reply Sequences" section does not contradict it.
               A multiple 1xx implementation is in accord with the
               formal reply specifications.

               A multiple 1xx implementation works with the TOPS-20
               FTP's and with a number of different UNIX
               implementations, and the LOCUS system.  So, a lot of
               implementors must follow state diagrams in preference to
               prose.

               However, the observation is certainly correct that
               page 34 of the specification suggests that 1xx replies
               can be used by single-thread user implementations to
               switch attention to the data connection.  This would
               allow only a single 1xx message, in contradiction to the
               state diagrams.  It seems a bit strong, however, to call
               the one sentence on page 34 "the intent" of the
               specification, since it is contradicted by the format
               specification of replies.



Reynolds & Postel                                              [Page 18]



Official ARPA-Internet Protocols                                 RFC 944


               A side discussion favoring more status information:

                  One view has always assumed a two-thread
                  implementation.  In this view, most user
                  implementations are deficient because they do not
                  allow the user to enter a STATUS command during data
                  transfer.  A cynic might say that is because the
                  Computer Scientists who did these implementations only
                  do "Toy" file transfers, and often use "Toy" operating
                  systems.

                  There has been some complaints from the Toy systems
                  crowd recently that FTP is too complicated.  Well, it
                  may be too complicated for Toy systems, but in fact it
                  is too simple for many Real file systems.  For
                  example, it has no way to encode a "library" (i.e., a
                  named collection of subfiles).  It is (barely)
                  adequate for shipping around files of text, but not
                  much more.

                  With the notable exception of Multics and UNIX, many
                  operating systems support complex file structures of
                  which the user must be aware.  One is not doing the
                  user a favor by hiding details that may reach out and
                  bite him.  That is the reason some FTPs put out a
                  large informative message at the beginning of the
                  transfer, specifying the file baroqueness that is
                  involved.  As a Computer Scientist, you may find that
                  message annoying, but if you had to use MVS very much,
                  you would find it helpful, informative, and maybe even
                  reassuring.  Some believe that as DARPA technology
                  moves into the production environment of DDN, there
                  will be user requirements for such informative
                  messages for a variety of vendor operating systems.

               To provide important information to the user the
               specification should either allow multiple 1xx messages,
               or restore the old spontaneous reply category.  In fact,
               the latter is preferable; this information should be
               displayed to the user, but a user FTP might swallow 1xx
               messages without displaying their text.

            The Answer:

               Following the Robustness Principle (a protocol
               implementation ought to inflict minimal pain and accept
               maximal pain) there should be only one 1xx response.
               That is, those FTP servers that now issue two 1xx
               responses should combine them.


Reynolds & Postel                                              [Page 19]



Official ARPA-Internet Protocols                                 RFC 944


      OTHER REFERENCES:

         RFC 678 - Document File Format Standards

         MIL-STD-1780 - File Transfer Protocol

      DEPENDENCIES: Transmission Control Protocol

      CONTACT: [e-mail]

   Trivial File Transfer Protocol  ------------------------------ (TFTP)

      STATUS:  Elective

      SPECIFICATION:  RFC 783 (in IPTW)

      COMMENTS:

         A very simple file moving protocol, no access control is
         provided.

         This is in use in several local networks.

         Ambiguities in the interpretation of several of the transfer
         modes should be  clarified, and additional transfer modes could
         be defined.  Additional error codes could be defined to more
         clearly identify problems.

      OTHER REFERENCES:

      DEPENDENCIES: User Datagram Protocol

      CONTACT: [e-mail]

   Simple File Transfer Protocol  ------------------------------- (SFTP)

      STATUS:  Experimental

      SPECIFICATION:  RFC 913

      COMMENTS:

         SFTP is a simple file transfer protocol.  It fills the need of
         people wanting a protocol that is more useful than TFTP but
         easier to implement (and less powerful) than FTP.  SFTP
         supports user access control, file transfers, directory
         listing, directory changing, file renaming and deleting.

         SFTP can be implemented with any reliable 8-bit byte stream


Reynolds & Postel                                              [Page 20]