home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / rfc / rfc1440 < prev    next >
Text File  |  1993-07-22  |  17KB  |  508 lines

  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                           R. Troth
  8. Request for Comments: 1440                               Rice University
  9.                                                                July 1993
  10.  
  11.  
  12.           SIFT/UFT: Sender-Initiated/Unsolicited File Transfer
  13.  
  14. Status of this Memo
  15.  
  16.    This memo defines an Experimental Protocol for the Internet
  17.    community.  It does not specify an Internet standard.  Discussion and
  18.    suggestions for improvement are requested.  Please refer to the
  19.    current edition of the "IAB Official Protocol Standards" for the
  20.    standardization state and status of this protocol.  Distribution of
  21.    this memo is unlimited.
  22.  
  23. 1.  Introduction
  24.  
  25.    This document describes a Sender-Initiated File Transfer (SIFT)
  26.    protocol, also commonly called Unsolicited File Transfer (UFT)
  27.    protocol.  The acronyms SIFT and UFT are synonymous throughout this
  28.    document.  The term "unsolicited" does not imply that the file is
  29.    unwanted, but that the receiver did not initiate the transaction.
  30.  
  31.    Sender-Initiated File Transfer contrasts with other file transfer
  32.    methods in that the sender need not have an account or any
  33.    registration on the target host system, and the receiving user may
  34.    have less steps to take to retrieve the file(s) sent.  Unlike
  35.    traditional file transfer, UFT lends itself handily to background or
  36.    deferred operation, though it may be carried out immediately, even
  37.    interactively.
  38.  
  39. 2.  Rationale
  40.  
  41.    In certain non-IP networks, notably NJE based networks such as
  42.    BITNET, it is possible to send a file to another user outside of the
  43.    realm of "mail".  The effect is that the file sent is not perceived
  44.    as correspondence and not processed by a mail user agent.  This
  45.    convenient service is missed in the standard TCP/IP suite.  The
  46.    author maintains that traditional electronic mail is not suited to
  47.    non-correspondence file transfer.  There should be a means of sending
  48.    non-mail, analogous to the sending of parcels rather than surface
  49.    mail.  Several groups and individuals have shown an interest in this
  50.    type of service.
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Troth                                                           [Page 1]
  59.  
  60. RFC 1440                        SIFT/UFT                       July 1993
  61.  
  62.  
  63. 3.  Specification
  64.  
  65.    We define sender-initiated file transfer for IP as a TCP service as
  66.    follows: a receiver program (the server or "daemon") listens on port
  67.    608 for inbound connections.  Client programs connect to this port
  68.    and send a sequence of commands followed by a stream of data.  The
  69.    entire job stream may be thought of as the concatenation of two
  70.    files, 1) a control file, and 2) a data file, where the control file
  71.    is plain text and the data file may be any of several formats, but is
  72.    stored and sent as binary.  After each command, the receiver either
  73.    ACKs (signals positive acknowledgement) or NAKs (signals negative
  74.    acknowledgement).  The target host may reject a file for various
  75.    reasons, most obvious being 1) that there is no local user matching
  76.    the intended user, or 2) that there is not enough space to hold the
  77.    incoming file.
  78.  
  79.    Most UFT commands are parametric.  That is, they don't necessarily
  80.    invoke an action as much as change parameters of the one action,
  81.    transfer of the file(s) being sent.  This means that UFT is suitable
  82.    for encapsulation in some higher-level "envelope", such as mail.
  83.    However, the obvious prefered medium for UFT is TCP.
  84.  
  85.    When files arrive at the destination host, they are kept in a public
  86.    area, say /usr/spool/uft, until accepted or rejected by the recipient
  87.    user or discarded for age by the system.  This staging area is public
  88.    in the sense of shared space, not unrestricted access.  Exactly how
  89.    long files may remain unprocessed and exactly how large these
  90.    transient files may be is a local administrative or implementation
  91.    decision.
  92.  
  93.    But not all hosts have IP connectivity; not all hosts will want to
  94.    put up yet another server; not all hosts will be on the unrestricted
  95.    side of a "fire wall" that only passes mail.  In such cases, UFT may
  96.    be transported via MIME (Multipurpose Internet Mail Extensions) as
  97.    Content-Type: application/octet-stream.  UFT commands then become
  98.    parameters to the Content-Type field and the data file is carried as
  99.    the mail body.  While the data file is carried in raw (binary) form
  100.    over TCP, it is encoded in BASE64 when carried by mail.
  101.  
  102.    UFT supports several representation types.  The receiving host should
  103.    accept any file type sent.  If the representation type is not
  104.    meaningful to the target host system, then it should be treated as
  105.    "binary" (image).  The data file (body) should be processed as little
  106.    as possible until the target user (recipient) acts to accept
  107.    (receive) it.  The commands from the client may be stored in the form
  108.    of a plain-text file so that processing otherwise foreign to the
  109.    receiver may be off-loaded from the TCP listener.  So there are
  110.    actually two files: the command sequence and the file body.
  111.  
  112.  
  113.  
  114. Troth                                                           [Page 2]
  115.  
  116. RFC 1440                        SIFT/UFT                       July 1993
  117.  
  118.  
  119.    Job Entry capability:
  120.  
  121.       The target "user" may actually be no user at all, but may be the
  122.       name of some software service engine.  An example of this is the
  123.       job entry queue available as a pseudo-user on many NJE networked
  124.       hosts.
  125.  
  126. 4.  Essential commands and Syntax:
  127.  
  128.         FILE    size    sender    [auth]
  129.         USER    recipient
  130.  
  131.         TYPE    type   [parm]
  132.  
  133.         Representation Types:
  134.  
  135.         TYPE        A           ASCII, CR/LF (0D/0A)
  136.                     B           binary (image; octet stream)
  137.  
  138.                     C           ASCII, CC, CR/LF (ASA print)
  139.  
  140.                     U           unformatted (binary; image)
  141.                     V           var-length records (16 bit)
  142.                     W           wide var-len records (32 bit)
  143.                     X           extra-wide var-length (64 bit)
  144.  
  145.                     I           image (binary; octet stream)
  146.                     E           EBCDIC, NL (15)
  147.                     F  reclen   fixed-length records (binary)
  148.  
  149.                     N           NETDATA
  150.                     M           ASCII, mail
  151.  
  152.         Additional Parameters:
  153.  
  154.         NAME    filename
  155.         DATE    date    time    [time-zone]
  156.  
  157.         CLASS   class
  158.         FORM    paper-form-code  or  print-stock-code
  159.         DEST    destination
  160.  
  161.         DIST | BIN | BOX        distribution-code  or  mail-stop
  162.         FCB | CTAPE             forms-control-buffer  or  carriage-tape
  163.         UCS | CHARSET | TRAIN   print-train  or  character-set
  164.  
  165.         LRECL           logical-record-length
  166.         RECFM           record-format
  167.  
  168.  
  169.  
  170. Troth                                                           [Page 3]
  171.  
  172. RFC 1440                        SIFT/UFT                       July 1993
  173.  
  174.  
  175.         BLKSIZE         block-size
  176.  
  177.         MODE            file access permissions
  178.  
  179.         File disposition commands:
  180.  
  181.         DATA  [burst-size]
  182.  
  183.         EOF
  184.         ABORT
  185.  
  186.         QUIT
  187.  
  188. 5.  Details:
  189.  
  190.    Commands consist of command words, possibly followed by tokens
  191.    delimited by white space.  Command lines are ASCII terminated by
  192.    CR/LF.  White space may be composed of any mixture of blanks or tab
  193.    characters, but use of ordinary blank space (ASCII 0x20) is strongly
  194.    recommended.
  195.  
  196.    One connection (one socket) is used for both commands and data.
  197.    While a data burst is being received, command interpretation is
  198.    suspended.  Command lines are read until CR/LF; data bursts are read
  199.    until burst-size number of octets are received, at which point
  200.    command interpretation is resumed.  After data transmission has
  201.    begun, the only commands valid are DATA, EOF, ABORT and QUIT.  EOF
  202.    causes the server to close the file at the receiving end and return
  203.    to normal command processing.  ABORT signals that the client wishes
  204.    to discard a file partially transmitted.  QUIT closes any open file,
  205.    closes the connection, and can appear anywhere in the job.
  206.  
  207.    For the daring, a "fast" mode is available.  If the burst-size token
  208.    is omitted from the DATA command, processing switches to data mode
  209.    and the stream is read until the client closes the connection.  In
  210.    this case there is no EOF or QUIT command sent.  NOTE: with the
  211.    former mode of operation, the connection may remain open indefinitely
  212.    passing multiple files, while in this latter case the connection must
  213.    close to terminate the transaction.
  214.  
  215.    Acknowledgement is by simple "NULL ACK".  A server accepts a command
  216.    by sending a single packet back to the client that starts with a NULL
  217.    character, decimal 0.  Anything else may be considered negative
  218.    acknowledgement, and the client should close the connection.  Any
  219.    characters following the NULL may be ignored.  An ACK response packet
  220.    may signal only one acknowledgement.
  221.  
  222.    When a client first connects to a server, the server immediately
  223.  
  224.  
  225.  
  226. Troth                                                           [Page 4]
  227.  
  228. RFC 1440                        SIFT/UFT                       July 1993
  229.  
  230.  
  231.    sends a herald of the form:
  232.  
  233.                 xxx hostname UFT 1.0 server-version xxx
  234.  
  235.    where "xxx" represents arbitrary data.  The first "xxx" must be a
  236.    single blank delimited token.  1.0 is the protocol version.  Hostname
  237.    is the IP name of the host where this server is running.  Server-
  238.    version is the name and level of UFT server code on this host.
  239.  
  240.    A US English server might send:
  241.  
  242.                 100 ricevm1.rice.edu UFT 1.0 VM/CMS-0.9.2 ready.
  243.  
  244.    The purpose of this herald is partly for client/server
  245.    synchronization, but mainly for protocol agreement.  There may be
  246.    future versions of UFT beyond 1.0 which support more features than
  247.    are outlined here.  The herald indicates what level of UFT the server
  248.    will accept.
  249.  
  250.    The FILE Command:
  251.  
  252.                 FILE    size    from    [auth]
  253.  
  254.    The size is in bytes and may be followed by an 'M', 'K', or 'G',
  255.    indicating Mega, Kilo, or Giga.  Size may be an inexact value (the
  256.    data file will be read until one of the above end-of-file indications
  257.    is received).  The size specified is used to answer the question, "is
  258.    there room for it?"
  259.  
  260.    The from token is the login name of the user sending this file.
  261.  
  262.    The auth token is an unimplemented authentication ticket.
  263.    Authentication is not ensured in the protocol as described.  There
  264.    are several ways that it might be added to UFT over TCP, but this
  265.    author will wait for authentication developments by others to come to
  266.    fruition before implementing any.  When UFT is piggy-backed on mail,
  267.    authentication is left to the mail transfer system.
  268.  
  269.    The FILE command is required in any transaction.
  270.  
  271.    The USER Command:
  272.  
  273.                 USER    recipient
  274.  
  275.    The recipient is a valid local user or service name.
  276.  
  277.    The USER command is required in any transaction.  Without it, the
  278.    destination of the file is unknown.
  279.  
  280.  
  281.  
  282. Troth                                                           [Page 5]
  283.  
  284. RFC 1440                        SIFT/UFT                       July 1993
  285.  
  286.  
  287.    The TYPE Command:
  288.  
  289.                 TYPE    type   [parm]
  290.  
  291.    Some representation types need additional specification.  As an
  292.    example, the type "F" (fixed length, record oriented) obviously needs
  293.    more qualification.  How long are these fixed length records?  A
  294.    record length in ASCII decimal should follow the "F" resulting in a
  295.    command like "TYPE F 80".
  296.  
  297.    UFT types V, W, X use a tape model for file transfer.  Files in
  298.    transit consist of blocks that vary in size based on the range of
  299.    sizes specifiable with 16, 32, or 64 bits, respectively.  Whether the
  300.    blocking is significant to the recipient is the decision of the
  301.    recipient, but if the file originally had some kind of blocking, it
  302.    is preserved without additional processing.  In the stream, the 16,
  303.    32, or 64-bit block length is prepended to each record in TCP/IP
  304.    network order.
  305.  
  306.    Type N (NETDATA) is an IBM representation common on NJE networks.
  307.  
  308.    The TYPE command is required in any transaction.
  309.  
  310.    The NAME Command:
  311.  
  312.                 NAME    filename
  313.  
  314.  
  315.    A name should typically be associated with the file being sent,
  316.    although this is not mandatory.   This is a mixed case token
  317.    delimitted by white space.   If the filename contains blanks or white
  318.    space, it must be quoted.   Quotation is not valid within the
  319.    filename. ASCII control characters (hex 00 thru 1F and 80 thru 9F)
  320.    are not valid as part of the filename.  Some characters may have
  321.    special meaning to the receiving operating system and their effect is
  322.    not guaranteed.
  323.  
  324.    The NAME command is optional.
  325.  
  326.    The DATE Command:
  327.  
  328.                 DATE    date    time    [time-zone]
  329.  
  330.    The time stamp on the file as it appears at the sending site may be
  331.    sent and applied to the copy at the receiving site.  The form is US
  332.    mm/dd/yy and hh:mm:ss.  A time zone is optional.  If the time zone is
  333.    omitted, local time is assumed.  If the DATE command is omitted, time
  334.    and date of arrival are assumed.
  335.  
  336.  
  337.  
  338. Troth                                                           [Page 6]
  339.  
  340. RFC 1440                        SIFT/UFT                       July 1993
  341.  
  342.  
  343.    The DATE command is optional.
  344.  
  345.    The DATA Command:
  346.  
  347.                 DATA  [burst-size]
  348.  
  349.    If no data bursts have yet been received since the connection was
  350.    opened or since an EOF or ABORT was received, the server opens a new
  351.    file on the receiving end and writes this burst of data to it.  The
  352.    file may have already been created by a prior DATA command.  There
  353.    can be any number of DATA commands; most files will be sent using
  354.    many data bursts.  If burst-size is supplied, then burst-size number
  355.    of octets are read and appended to the open file on the receiving end
  356.    and the server returns to the command state.  If no burst-size
  357.    parameter is given, then the TCP stream is read until it is closed.
  358.    (this is the "fast" mode mentioned above)
  359.  
  360.    The DATA command must come after FILE, USER, TYPE, and any other
  361.    parametric commands and must come before any EOF or ABORT command.
  362.    The file need not be complete before an ABORT can be received and
  363.    carried out, but the DATA command must have completed (burst-size
  364.    number of octets must have been read), thus ABORT is not possible in
  365.    "fast" mode.
  366.  
  367.    The EOF Command:
  368.  
  369.                 EOF
  370.  
  371.    This signals the server that the entire file has been sent.  The
  372.    server then closes the file and ensures that it is disposed of
  373.    appropriately, usually just placing it where a user-level application
  374.    can retrieve it later.
  375.  
  376.    The ABORT Command:
  377.  
  378.                 ABORT
  379.  
  380.    This signals the server that the client is unable or unwilling to
  381.    finish the job.  The file should be discarded and the server should
  382.    return to normal command processing.
  383.  
  384.    The QUIT Command:
  385.  
  386.                 QUIT
  387.  
  388.    This signals the server that all work is complete.  Any open file
  389.    should be closed and delivered.  The TCP stream will be closed.
  390.  
  391.  
  392.  
  393.  
  394. Troth                                                           [Page 7]
  395.  
  396. RFC 1440                        SIFT/UFT                       July 1993
  397.  
  398.  
  399.         Other commands:
  400.  
  401.         CLASS       class
  402.         FORM        paper-form-code  or  print-stock-code
  403.         DEST        destination
  404.         DIST        distribution-code  or  mail-stop
  405.         FCB         forms-control-buffer  or  carriage-tape
  406.         CHARSET     print-train  or  character-set
  407.  
  408.         The above are relevant to print jobs sent to a print server.
  409.  
  410.         LRECL       logical-record-length
  411.         RECFM       record-format
  412.         BLKSIZE     block-size
  413.         MODE        file access permissions
  414.  
  415. 6.  References
  416.  
  417.         NJE        --   Network Job Entry; IBM publication SC23-0070,
  418.                         "Network Job Entry; Formats and Protocols"
  419.  
  420.         NETDATA    --   see IBM publication aann-nnnn (SC24-5461);
  421.                         VM/ESA: CMS Application Development Reference
  422.                         for Assembler
  423.  
  424.         BITNET     --   "Because It's Time"; academic network
  425.                         based on NJE protocol
  426.  
  427.         MIME       --   RFC 1341; Multipurpose Internet Mail Extensions;
  428.                         Borenstein & Freed
  429.  
  430.         FTP        --   File Transfer Protocol; STD 9, RFC 959;
  431.                         Postel & Reynolds
  432.  
  433.         SMTP       --   STD 10, RFC 821; Simple Mail Transfer
  434.                         Protocol; Postel
  435.  
  436.         LPR        --   UNIX Programmer's Manual, LPD(8);
  437.                         4.2BSD Line Printer Spooler Manual
  438.  
  439. 7.  Security Considerations
  440.  
  441.    Security issues are not discussed in this memo.
  442.  
  443.  
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450. Troth                                                           [Page 8]
  451.  
  452. RFC 1440                        SIFT/UFT                       July 1993
  453.  
  454.  
  455. 8.  Author's Address
  456.  
  457.    Rick Troth
  458.    Rice University
  459.    Information Systems
  460.    Houston, Texas 77251
  461.  
  462.    Phone: (713) 285-5148
  463.    Fax: (713) 527-6099
  464.    EMail: troth@rice.edu
  465.  
  466.  
  467.  
  468.  
  469.  
  470.  
  471.  
  472.  
  473.  
  474.  
  475.  
  476.  
  477.  
  478.  
  479.  
  480.  
  481.  
  482.  
  483.  
  484.  
  485.  
  486.  
  487.  
  488.  
  489.  
  490.  
  491.  
  492.  
  493.  
  494.  
  495.  
  496.  
  497.  
  498.  
  499.  
  500.  
  501.  
  502.  
  503.  
  504.  
  505.  
  506. Troth                                                           [Page 9]
  507.  
  508.