Use of FTP by the NIC Journal
RFC 479

Document Type RFC - Unknown (March 1973; No errata)
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf html bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 479 (Unknown)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                               James E. White (JEW)
Request for Comments:  479                                       SRI-ARC
NIC: 14948                                                 March 8, 1973

                     Use of FTP by the NIC Journal

   At the Network Mail Meeting (see -- 14317,) the NIC outlined it's
   requirements for implementing FTP Journal delivery and submission.

   It had always been our thinking that those two services should rely
   upon the File Transfer Protocol's MLFL command for their

   Prior to the meeting, we had envisioned that, in the case of
   submission, for example, the user would embed what parameters the NIC
   required (e.g., an indication that this piece of mail was to be
   journalized, a list of NIC idents, etc.) in the USERNAME field of the
   MLFL command, in a way that was transparent to his FTP user process,
   and that SRI-ARC's FTP server process would parse the 'user name' for
   the parameters and internally invoke the Journal System with them and
   the text of the mail as arguments.

      Our goal (which this scheme would have satisfied) was to provide
      the desired services while confining software changes to our own
      system and, in particular, to avoid requiring that user FTP
      processes or the File Transfer Protocol itself be modified.

   It was, however, the consensus of those present at the meeting that
   it was preferable to modify FTP in such a way that all required
   parameters could be explicitly declared, rather than require that
   they be hidden within what purported to be simply a user name.

   The intent of this RFC is to list what we (the NIC) believe were the
   new FTP commands it was agreed should be defined in support of mail
   submission and delivery. Actually, we've done some massaging after
   thinking about the issues for awhile, and so this is really a
   description of what we'd like to see included in the File Transfer
   Protocol (following the lines of thought which developed at the
   meeting), along with a short description of how the NIC would use

   Some of the commands currently make sense only if issued TO the NIC's
   FTP server process (as opposed to anybody else's) and others only if
   issued BY the NIC's FTP user process (as opposed to anybody else's).
   This is true because currently only the NIC plans to offer mail

White                                                           [Page 1]
RFC 479              Use of FTP by the NIC Journal            March 1973

   forwarding and recording (i.e., the Journal System) as a service.
   However, other hosts may in the future desire to implement a similar
   service, at which time these special commands will have wider use.

   Conceptually, all of these commands are sub-commands of a new MAIL
   command, but the intent for the moment is not to define their
   position within the FTP dialogue nor their syntax, but simply to
   describe them conceptually.  Details of syntax and use are left to
   the FTP Interest Group which meets 16-MAR-73 in Boston (see --

   The new sub-commands are described below.  Bracketed fields are
   optional; slash denotes a choice of two or more alternatives.

      (1)  TITLE title

         Where 'title' is a character string describing for the human
         reader the contents of the mail.

      (2)  USER-READABLE-AUTHOR author

         Where 'author' identifies the author of the mail to the human
         reader.  This may be a nickname, or any other identifier with
         which the human sender chooses to sign his mail.

      (3)  PROCESS-READABLE-AUTHOR last, first initial (ident)

         Where the author's name (and ident if known) is made available
         to the server in a form it can hope to parse (if need be).

         This sub-command is important to the NIC, providing a basis for
         locating the author in the NIC's Ident files.

      (4)  FOR-ACKNOWLEDGMENT-AUTHOR username hostname

         Where 'username' and 'hostname' define the sender in a way
         useful in acknowledging delivery (of forwarded mail).

            The acknowledgment will itself be a piece of mail sent from
            the NIC to 'username' at 'hostname'.

         It's important, conceptually, to note the NIC's unique role
         here.  Normally, acceptance of the mail by the server would
         constitute acknowledgment of delivery.  But, in the case of
         Journal submission, the NIC acts only as a forwarding agent,
         and hence delivery of mail by the sender to SRI-ARC isn't

White                                                           [Page 2]
RFC 479              Use of FTP by the NIC Journal            March 1973

         really delivery at all -- only submission.  Final delivery
         occurs when the NIC transmits a copy of the mail to each of its
         addressees; hence the need for this special kind of
Show full document text