rfc1440.txt

来自「<VC++网络游戏建摸与实现>源代码」· 文本 代码 · 共 507 行 · 第 1/2 页

Network Working Group                                           R. Troth
Request for Comments: 1440                               Rice University
                                                               July 1993


          SIFT/UFT: Sender-Initiated/Unsolicited File Transfer

Status of this Memo

   This memo defines an Experimental Protocol for the Internet
   community.  It does not specify an Internet standard.  Discussion and
   suggestions for improvement are requested.  Please refer to the
   current edition of the "IAB Official Protocol Standards" for the
   standardization state and status of this protocol.  Distribution of
   this memo is unlimited.

1.  Introduction

   This document describes a Sender-Initiated File Transfer (SIFT)
   protocol, also commonly called Unsolicited File Transfer (UFT)
   protocol.  The acronyms SIFT and UFT are synonymous throughout this
   document.  The term "unsolicited" does not imply that the file is
   unwanted, but that the receiver did not initiate the transaction.

   Sender-Initiated File Transfer contrasts with other file transfer
   methods in that the sender need not have an account or any
   registration on the target host system, and the receiving user may
   have less steps to take to retrieve the file(s) sent.  Unlike
   traditional file transfer, UFT lends itself handily to background or
   deferred operation, though it may be carried out immediately, even
   interactively.

2.  Rationale

   In certain non-IP networks, notably NJE based networks such as
   BITNET, it is possible to send a file to another user outside of the
   realm of "mail".  The effect is that the file sent is not perceived
   as correspondence and not processed by a mail user agent.  This
   convenient service is missed in the standard TCP/IP suite.  The
   author maintains that traditional electronic mail is not suited to
   non-correspondence file transfer.  There should be a means of sending
   non-mail, analogous to the sending of parcels rather than surface
   mail.  Several groups and individuals have shown an interest in this
   type of service.







Troth                                                           [Page 1]

RFC 1440                        SIFT/UFT                       July 1993


3.  Specification

   We define sender-initiated file transfer for IP as a TCP service as
   follows: a receiver program (the server or "daemon") listens on port
   608 for inbound connections.  Client programs connect to this port
   and send a sequence of commands followed by a stream of data.  The
   entire job stream may be thought of as the concatenation of two
   files, 1) a control file, and 2) a data file, where the control file
   is plain text and the data file may be any of several formats, but is
   stored and sent as binary.  After each command, the receiver either
   ACKs (signals positive acknowledgement) or NAKs (signals negative
   acknowledgement).  The target host may reject a file for various
   reasons, most obvious being 1) that there is no local user matching
   the intended user, or 2) that there is not enough space to hold the
   incoming file.

   Most UFT commands are parametric.  That is, they don't necessarily
   invoke an action as much as change parameters of the one action,
   transfer of the file(s) being sent.  This means that UFT is suitable
   for encapsulation in some higher-level "envelope", such as mail.
   However, the obvious prefered medium for UFT is TCP.

   When files arrive at the destination host, they are kept in a public
   area, say /usr/spool/uft, until accepted or rejected by the recipient
   user or discarded for age by the system.  This staging area is public
   in the sense of shared space, not unrestricted access.  Exactly how
   long files may remain unprocessed and exactly how large these
   transient files may be is a local administrative or implementation
   decision.

   But not all hosts have IP connectivity; not all hosts will want to
   put up yet another server; not all hosts will be on the unrestricted
   side of a "fire wall" that only passes mail.  In such cases, UFT may
   be transported via MIME (Multipurpose Internet Mail Extensions) as
   Content-Type: application/octet-stream.  UFT commands then become
   parameters to the Content-Type field and the data file is carried as
   the mail body.  While the data file is carried in raw (binary) form
   over TCP, it is encoded in BASE64 when carried by mail.

   UFT supports several representation types.  The receiving host should
   accept any file type sent.  If the representation type is not
   meaningful to the target host system, then it should be treated as
   "binary" (image).  The data file (body) should be processed as little
   as possible until the target user (recipient) acts to accept
   (receive) it.  The commands from the client may be stored in the form
   of a plain-text file so that processing otherwise foreign to the
   receiver may be off-loaded from the TCP listener.  So there are
   actually two files: the command sequence and the file body.



Troth                                                           [Page 2]

RFC 1440                        SIFT/UFT                       July 1993


   Job Entry capability:

      The target "user" may actually be no user at all, but may be the
      name of some software service engine.  An example of this is the
      job entry queue available as a pseudo-user on many NJE networked
      hosts.

4.  Essential commands and Syntax:

        FILE    size    sender    [auth]
        USER    recipient

        TYPE    type   [parm]

        Representation Types:

        TYPE        A           ASCII, CR/LF (0D/0A)
                    B           binary (image; octet stream)

                    C           ASCII, CC, CR/LF (ASA print)

                    U           unformatted (binary; image)
                    V           var-length records (16 bit)
                    W           wide var-len records (32 bit)
                    X           extra-wide var-length (64 bit)

                    I           image (binary; octet stream)
                    E           EBCDIC, NL (15)
                    F  reclen   fixed-length records (binary)

                    N           NETDATA
                    M           ASCII, mail

        Additional Parameters:

        NAME    filename
        DATE    date    time    [time-zone]

        CLASS   class
        FORM    paper-form-code  or  print-stock-code
        DEST    destination

        DIST | BIN | BOX        distribution-code  or  mail-stop
        FCB | CTAPE             forms-control-buffer  or  carriage-tape
        UCS | CHARSET | TRAIN   print-train  or  character-set

        LRECL           logical-record-length
        RECFM           record-format



Troth                                                           [Page 3]

RFC 1440                        SIFT/UFT                       July 1993


        BLKSIZE         block-size

        MODE            file access permissions

        File disposition commands:

        DATA  [burst-size]

        EOF
        ABORT

        QUIT

5.  Details:

   Commands consist of command words, possibly followed by tokens
   delimited by white space.  Command lines are ASCII terminated by
   CR/LF.  White space may be composed of any mixture of blanks or tab
   characters, but use of ordinary blank space (ASCII 0x20) is strongly
   recommended.

   One connection (one socket) is used for both commands and data.
   While a data burst is being received, command interpretation is
   suspended.  Command lines are read until CR/LF; data bursts are read
   until burst-size number of octets are received, at which point
   command interpretation is resumed.  After data transmission has
   begun, the only commands valid are DATA, EOF, ABORT and QUIT.  EOF
   causes the server to close the file at the receiving end and return
   to normal command processing.  ABORT signals that the client wishes
   to discard a file partially transmitted.  QUIT closes any open file,
   closes the connection, and can appear anywhere in the job.

   For the daring, a "fast" mode is available.  If the burst-size token
   is omitted from the DATA command, processing switches to data mode
   and the stream is read until the client closes the connection.  In
   this case there is no EOF or QUIT command sent.  NOTE: with the
   former mode of operation, the connection may remain open indefinitely
   passing multiple files, while in this latter case the connection must
   close to terminate the transaction.

   Acknowledgement is by simple "NULL ACK".  A server accepts a command
   by sending a single packet back to the client that starts with a NULL
   character, decimal 0.  Anything else may be considered negative
   acknowledgement, and the client should close the connection.  Any
   characters following the NULL may be ignored.  An ACK response packet
   may signal only one acknowledgement.

   When a client first connects to a server, the server immediately



Troth                                                           [Page 4]

RFC 1440                        SIFT/UFT                       July 1993


   sends a herald of the form:

                xxx hostname UFT 1.0 server-version xxx

   where "xxx" represents arbitrary data.  The first "xxx" must be a
   single blank delimited token.  1.0 is the protocol version.  Hostname
   is the IP name of the host where this server is running.  Server-
   version is the name and level of UFT server code on this host.

   A US English server might send:

                100 ricevm1.rice.edu UFT 1.0 VM/CMS-0.9.2 ready.

   The purpose of this herald is partly for client/server
   synchronization, but mainly for protocol agreement.  There may be
   future versions of UFT beyond 1.0 which support more features than
   are outlined here.  The herald indicates what level of UFT the server
   will accept.

   The FILE Command:

                FILE    size    from    [auth]

   The size is in bytes and may be followed by an 'M', 'K', or 'G',