1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
|
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
|
