The RFC Archive
 The RFC Archive   RFC 479   « Jump to any RFC number directly 
 RFC Home
Full RFC Index
Recent RFCs
RFC Standards
Best Current Practice
RFC Errata
1 April RFC



IETF RFC 479

Use of FTP by the NIC Journal

Last modified on Tuesday, May 16th, 2000

Permanent link to RFC 479
Search GitHub Wiki for RFC 479
Show other RFCs mentioning RFC 479







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
   implementation.

   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
   them.

   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 top


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 -- 14333,). 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 top

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 acknowledgment. Note that this sub-command and the previous two constitute different renderings of the sender's name. (5) ACKNOWLEDGMENT-DETAILS DEFAULT / (COMPLETION / FAILURE / PERIODIC interval GIVEUP time TERSE / VERBOSE) The value of the first parameter (ignoring 'DEFAULT' for the moment) determines the conditions under which acknowledgment will be made to the sender: -- upon completion, whether delivery was successful or timed out for one or more addressees, -- only if delivery failed for one or more addressees, or -- periodically until delivery is complete. The value of the second parameter determines the time after which delivery attempts will be discontinued. The value of the third parameter determines how detailed -- in some as yet unspecified sense -- an acknowledgment will be returned. A verbose acknowledgment might, in the case of delivery failure, include a copy of the text of the message, or, for mail sent by citation (see item 10 below), a pointer to it. If DEFAULT is specified (in which case, FOR-ACKNOWLEDGMENT- AUTHOR should not be specified, and 'DEFAULT' applies to it, too), the NIC will extract a set of default values from its Ident files, provided that a PROCESS-READABLE-AUTHOR subcommand is present and the sender's NIC Ident can be inferred from it; otherwise, the NIC will apply a set of (as yet unspecified) system defaults. The NIC's Ident files will be modified to contain, for each user known to it, the kind of acknowledgment the user usually wants (i.e., his default) and the username and hostname that define the destination for such acknowledgments. These last two pieces of information will White PAGE 3 top

RFC 479 Use of FTP by the NIC Journal March 1973 also be used in delivering mail to the user if he has requested Network delivery (as opposed to Online (at the NIC) or hardcopy). (6) ADDRESSEES-ARE name1, name2, ... This sub-command identifies the recipient(s) of the mail. In general, 'namei' will be the name by which the recipient is known locally in the server's system. The NIC's server FTP process will permit 'namei' to be any of the following: -- a NIC Ident (designating either an individual or a group), -- username hostname, where 'username' is the name by which the addressee is known at host 'hostname', or -- lastname, firstname initial , which the NIC will attempt to parse and then locate in its Ident files. Note that now the possibility of multiple addressees is explicitly admitted by the Protocol, but the meaning of 'useri' (to the server) is left server-dependent. (7) MAIL-CLASS BULK/POSTCARD SPECIAL-DELIVERY/FIRST-CLASS The first parameter makes a statement about the size of the mail, and the server may choose to use it to decide how and where to store he mail for the addressee. The second parameter makes a statement about the importance of the mail, and the server may choose to expedite delivery (e.g., interrupt the user if he's logged in) for SPECIAL-DELIVERY mail. (8) RECORD [identifier] [miscellaneous] This is the command to the server to record the mail. 'Identifier' allows the sender the option of specifying a pre- assigned identifier if he has one; if this field is not present, the server assigns one. 'Miscellaneous' includes any server-dependent parameters which the server may require or allow. White PAGE 4 top

RFC 479 Use of FTP by the NIC Journal March 1973 When this command is issued to the NIC, it will be taken as a command to Journalize the mail, and 'identifier' may be: NIC number [RFC number] The NIC may allow 'miscellaneous' to contain such information as comments, keywords, etc. (9) PRESERVED-AT hostname AS identifier This is not a command but a statement of fact which the FTP server will presumably relay to the user as it does the information contained in (for example) the TITLE command. The implication is that a copy of this piece of mail has been preserved at 'hostname' and is retrievable -- on a long-term basis -- with 'identifier'. 'Identifier' might, in general, be a pathname. When the NIC delivers Journal articles through the Net, it will include this sub-command, and 'identifier' will be a NIC number, and 'hostname' of course 'SRI-ARC' or 'NIC'. (10) TEXT text FILE pathname hostname One of these two sub-commands is used to actually transmit the mail: the first transmits the text of the mail, the second a pointer to it (leaving open to the FTP server (or his user) the option of retrieving the text of the mail from the specified host). The NIC will transmit mail created within NLS with 'Submit File' using the FILE command, and mail created with 'Submit Message' using the TEXT command. For mail entering the SRI- ARC system via its FTP server process, the NIC will employ the same command in delivery as was used in submission. [ This RFC was put into machine readable form for entry ] [ into the online RFC archives by Hannes Faestermann 12/97 ] White PAGE 5 top

Use of FTP by the NIC Journal RFC TOTAL SIZE: 11183 bytes PUBLICATION DATE: Tuesday, May 16th, 2000 LEGAL RIGHTS: The IETF Trust (see BCP 78)


RFC-ARCHIVE.ORG

© RFC 479: The IETF Trust, Tuesday, May 16th, 2000
© the RFC Archive, 2024, RFC-Archive.org
Maintainer: J. Tunnissen

Privacy Statement