blob: 5a105ba8401a12255612aab36dbe7baec66a31af (
plain) (
blame)
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
|
Network Working Group Abhay K. Bhushan
RFC # 463 MIT-DMCG
NIC # 14573 February 21, 1973
FTP Comments and Response to RFC 430
Most of the comments in RFC 430 by Bob Braden are useful suggestions
which should be included in the forthcoming official FTP specification.
This RFC represents my response to Braden's comments and other views.
These comments should be useful for the FTP meeting on March 16 at BBN
(announcement warning AAM NIC #14417). The results of the FTP subgroup
meeting held at BBN on January 25 will be published in RFC 4541 (are
published?).
SPECIFIC RESPONSES TO RFC 430.
Item A1 - I will let Bob Braden handle the "print file" issues (the
"still" should be removed).
Item A2 - I agree that concessions are undesirable and should be
removed unless people cannot "live" without them.
Item A3 - I strongly support "bit flag coding" for descriptors.
Other definition improvement suggestions are ok too.
Item A4 - The diagram was useful. An alternate one is given on page
17 of RFC 454. I prefer the latter.
Item A5 - The FTP may not be privileged enough to alter passwords
in many Host systems (e.g. Multics). I know that CCN allows changing
passwords on-line. We can define a format for changing passwords in
the pass command, but I don't think we can require that all servers
allow password changing. This is a minor problem that can be easily
solved.
Item A6 - Yes, the comment that TYPE should be before BYTE was for
bad implementations. The server should reject data transfer
parameters only when the data transfer command is received. The
order of the parameter-change commands is not important.
Item A7 - I do agree that NCP's should be fixed. A 255 (socket
number) reply should be required at a specific time, and NCP's
should be able to provide it (this also permits the proposed GSOC
command). Let us find out at next meeting if there is anyone who
cannot live with this new requirement.
Bhushan [Page 1]
^L
RFC 463 FTP Comments and Response to RFC 430 February 1973
Item A8 - Yes.
Item B - There are at least two ways to solve the FTP parameter
encoding problem presented by Bob Braden. One is to allow multiple
letter in the TYPE command as suggested by Bob and the other is to
have a new command such as FORM (which could be P or U). Other
solutions are equally acceptable to me.
Item C - Our emphasis should be on working protocol as well as
elegance. I like the proposed GSOC command over the listen. In fact
GSOC can be used for all data connection security checking. The 255
reply should be sent with GSOC only, and the server should use only
those sockets for data connection.
Item D - We need more discussion on the issue of site dependent FTP
parameters. I will put it on the agenda for the forthcoming FTP
meeting.
FURTHER COMMENTS
1. The command-reply sequence needs to be tightened in both
specification and implementations to allow convenient use of FTP by
programs or "automatons".
2. A 300 reply greeting upon first connecting to the FTP server
should be required and not optional. This avoids the programs having
to wait an arbitrary time for such a greeting before issuing
commands. Commands may only be sent after the 300 reply is received
from the server.
3. RFC 454 needs a discussion of transfer between two FTP servers
arranged by the user via the LSTN or GSOC commands.
4. Perhaps we should allow specification of data transfer parameters
in a single command line (for reasons of efficiency). A suggested
format is to have <SP> separate the parameters bunched together in a
single line (requiring only a single reply). Consider the following
sequences:
STRU F TYPE I BYTE 36 MODE S <CR><LF>
reply - 200 OK
5. Further discussion of MAIL and MAIL.file commands seems
necessary. Perhaps we will get some useful input from the MAIL
meeting at SRI on February 23, The following issues seem
particularly relevant to me:
a) Allowing mail to multiple users. It should be required that
FTP servers allow this.
Bhushan [Page 2]
^L
RFC 463 FTP Comments and Response to RFC 430 February 1973
b) Using NIC idents. FTP servers should accept some standard
form of user name. This could be NIC idents or last name with
optional use of initials.
c) Uniform conventions for who the mail is from, day, time,
etc., and how the mail is delivered to user. The mail usually gets
tagged twice or sometimes not tagged at all. Perhaps we need a
different mechanism for indicating who the mail is from than
provided by the USER command.
d) handling bulk or junk mail (particularly the NIC documents
that may be sent on-line by the NIC). Perhaps mail.file should put a
file in user's directory and notify him of the same. The user does
not see all the junk on his console but can print the file on a
printer and read that class of mail at his leisure.
[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by Alex McKenzie with ]
[ support from GTE, formerly BBN Corp. 9/99 ]
Bhushan [Page 3]
^L
|
